• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

pantsbuild / pants / 5725 / 2
71%
main: 93%

Build:
Build:
LAST BUILD BRANCH: update_setup_protoc
DEFAULT BRANCH: main
Ran 21 Jul 2015 05:51PM UTC
Files 336
Run time 15s
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

21 Jul 2015 05:50PM UTC coverage: 67.007%. First build
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)

13473 of 20107 relevant lines covered (67.01%)

0.67 hits per line

Source Files on job 5725.2 (CI_FLAGS="-fkmsrcn -u 0/2 'Unit tests for pants and pants-plugins - shard 1'")
  • Tree
  • List 0
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 5725
  • Travis Job 5725.2
  • e37d8d77 on github
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc