-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding DataDir to classpath in Scoverage #265
Comments
Thanks for opening this @sammy-1234. To expand on the purpose for this change: in a remote execution environment that uses the Bazel remoting API (so, Bazel, Pants, a few other soon most likely) each 1) compiler invoke, 2) test run, will happen in an anonymous working directory on an unknown machine. In particular, this means that:
This ticket proposes to fix both 1 and 2 by changing where the scoverage compiler plugin writes the xml it generates to be written in the compiler's output directory (ie, on the output classpath for the compiled sources). There is a convention of using subdirectories of the
Then, you would need to change the runtime behaviour of scoverage to consume the XML from the classpath, and to write its outputs to one of:
These changes allow for remote execution, but they also allow for caching, as with sbt's hoarder plugin (which would currently break with scoverage, afaict). |
Currently, the dataDir option is used to specify the path that the instruments and the measurements files are written to.
It would be beneficial to add an option in scoverage to include the dataDir in the classpath. This would provide more flexibility in systems that do not guarantee a local filesystem but a distributed one. For example, in #249, Pants compiles may happen in a remote machine. Classpaths are well-known and would provide a better and more stable future extensibility for the scalac-scoverage-plugin for generating reports in a distributed compilation.
The text was updated successfully, but these errors were encountered: