You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I discovered that no matter what I put into trailing arguments it will be ignored when running against sbt project and instead a generic task sourcegraphScip will be called that will eventually invoke compilation of the whole project.
Why this is an issue
This is particularly bad for project that cross-compile against multiple scala versions and/or platforms (most of the modern scala libraries) as such compilation can exceed available resources on the CI runner. In order to deal with limited resources scala projects often partition CI pipelines based on the scala version and target platform. Then, commands are invoked only against given pairs of (scalaVersion, targetPlatfor).
Besides that, it is also wasteful, as there is no need to compute that kind of information for every (scalaVersion, targetPlatfor). While there could be some specific sources for some of such pairs, afaik sourcegraph platform doesn't allow for submitting semantic data for different targets.
Expected behavior
I would expect scip-java to respect my trailing arguments and forward them to sbt. This would allow me to call scip-java as follows:
$ cs launch com.sourcegraph:scip-java_2.13:0.9.6 -- index -- compileScoped 2.13 JVM
where compileScoped is a custom task that will compile only 2.13 sources for JVM platform.
This would be also inline with the documentation that states:
TRAILING ARGUMENTS
Optional. The build command to use to compile all sources. Defaults to a
build-specific command. For example, the default command for Maven command is
'clean verify -DskipTests'.To override the default, pass in the build command
after a double dash: 'scip-java index -- compile test:compile'
Alternatives you have considered
The only alternative I can think of would be to use the manual configuration but using scip-java is more convenient as I don't want to deal with enabling semanticDB plugin at runtime. I also don't want to have the semanticDB plugin enabled by default as it slows down the compilation as stated in https://sourcegraph.github.io/scip-java/docs/benchmarks.html
Hi,
Actual behavior
I discovered that no matter what I put into trailing arguments it will be ignored when running against sbt project and instead a generic task
sourcegraphScip
will be called that will eventually invoke compilation of the whole project.Why this is an issue
This is particularly bad for project that cross-compile against multiple scala versions and/or platforms (most of the modern scala libraries) as such compilation can exceed available resources on the CI runner. In order to deal with limited resources scala projects often partition CI pipelines based on the scala version and target platform. Then, commands are invoked only against given pairs of
(scalaVersion, targetPlatfor)
.Besides that, it is also wasteful, as there is no need to compute that kind of information for every
(scalaVersion, targetPlatfor)
. While there could be some specific sources for some of such pairs, afaik sourcegraph platform doesn't allow for submitting semantic data for different targets.Expected behavior
I would expect
scip-java
to respect my trailing arguments and forward them to sbt. This would allow me to callscip-java
as follows:where
compileScoped
is a custom task that will compile only 2.13 sources for JVM platform.This would be also inline with the documentation that states:
Alternatives you have considered
The only alternative I can think of would be to use the manual configuration but using
scip-java
is more convenient as I don't want to deal with enablingsemanticDB
plugin at runtime. I also don't want to have thesemanticDB
plugin enabled by default as it slows down the compilation as stated in https://sourcegraph.github.io/scip-java/docs/benchmarks.htmlHow to reproduce
cs launch com.sourcegraph:scip-java_2.13:0.9.6 -- index -- compileScoped 2.13 JVM
The text was updated successfully, but these errors were encountered: