pantsbuild / pants / 5717 / 2
72%
main: 93%

LAST BUILD BRANCH: test_pants_with_uv_lockfiles
DEFAULT BRANCH: main
Ran
Files 337
Run time 20s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 67.402% (+0.4%) from 67.007%
CI_FLAGS="-fkmsrcn -u 0/2 'Unit tests for pants and pants-plugins - shard 1'"

push

travis-ci

Stu Hood 
[group_task][jvm] Precompute compile contexts for all targets

PROBLEM:
Zinc learns about analysis files when they are passed in analysis-map argument. We always supply the analysis files for all targets in the build graph every time we invoke Zinc. The problem is that the paths to the analysis- and class files are computed separately by ScalaCompile and JavaZincCompile. This happens in compile_context() for isolated strategy, where a path is computed by concatenating target.id to the task's workdir. Basically compile_context() is only suitable for computing the context for the task's own targets, but we're (ab)using it for all targets in the build graph, when computing the value for analysis-map argument. This means some of the paths are incorrect and non-existent: e.g. path to java target analysis is computed by ScalaCompile as compile/jvm/scala/isolated-analysis/storage.clients.manhattan.client.src.main.java.java, while it should be compile/jvm/zinc-java/isolated-analysis/storage.clients.manhattan.client.src.main.java.java. Such incorrect paths are not matched with classpath entries in _upstream_analysis(), and therefore the corresponding analysis files are not included in the analysis-map argument. This causes Zinc to consider cross-language dependencies as binary dependencies and compare timestamps, which is suboptimal.

SOLUTION:
Compute the paths to analysis files more intelligently. The CompileContexts are computed in prepare_compile() (for both strategies) and saved in a global (target -> compile_context) map belonging to GroupTask. Then in compile_chunk(), this global map is used instead of calling _create_compile_contexts_for_targets(). This also possibly solves the boundary between tasks using global strategy (I believe they all map to same analysis and classdir) and the ones using isolated strategy.

DOWNSIDE:
GroupTask is now aware of the fact that it's in fact a compilation task, as does GroupMember. This was bound to happen anyway sinc... (continued)

13618 of 20204 relevant lines covered (67.4%)

0.67 hits per line

Source Files on job 5717.2 (CI_FLAGS="-fkmsrcn -u 0/2 'Unit tests for pants and pants-plugins - shard 1'")