pantsbuild #general

Channels

welcome

github-notifications

announce

high-advantage-47550

01/20/2017, 2:42 PM

If I do a

./pants X

, and then

./pants X

again (with no changes in-between), why would some targets return a

against the cache?

high-advantage-47550

01/20/2017, 2:42 PM

Is there some key that I’m not keeping consistent?

high-advantage-47550

01/20/2017, 2:45 PM

relatedly, do most people do

compile

compiled-changed

in CI?

billions-airport-86951

01/20/2017, 5:01 PM

is anyone working on a JaCoCo plugin for Pants?

wide-energy-11069

01/20/2017, 5:32 PM

@billions-airport-86951 there's coverage with cobertura, but no jacoco yet

wide-energy-11069

01/20/2017, 5:33 PM

it could be good from intellij users’ perspective, because it’s able to parse jacoco’s output, but not cobertura

billowy-minister-38128

01/20/2017, 7:20 PM

@witty-crayon-22786 no joy using 1.2.1rc0

happy-kitchen-89482

01/22/2017, 5:25 AM

@high-advantage-47550 What is

./pants X

? For most tasks, rerunning should be a no-op and the cache shouldn't even be consulted.

acceptable-scooter-37412

01/23/2017, 1:29 PM

Hi folks, wondered if anyone might be able to help me debug a problem

acceptable-scooter-37412

01/23/2017, 1:29 PM

i can quickly set the scene

acceptable-scooter-37412

01/23/2017, 1:29 PM

we have a plugin task that is registered for the

resources

goal

acceptable-scooter-37412

01/23/2017, 1:30 PM

and we have it configured such that the task is run for every

jvm_binary

target

acceptable-scooter-37412

01/23/2017, 1:32 PM

this task -- called

build_properties_task

-- writes a

build.properties

file containing a bunch of information that we find useful for the build -- e.g. the git commit hash, list of most recent previous commits, etc.

acceptable-scooter-37412

01/23/2017, 1:32 PM

and the

build.properties

then gets bundled in to the final jar when we run

./pants build

against a

jvm_binary

target

acceptable-scooter-37412

01/23/2017, 1:33 PM

OK, hope that sets the scene a little

acceptable-scooter-37412

01/23/2017, 1:34 PM

the problem is that different people running the same

./pants build

against the same

jvm_binary

target can end up with different build.properties results -- e.g. they might get different commit hashes, even if both are running the command while checked out on same branch

acceptable-scooter-37412

01/23/2017, 1:35 PM

furthermore, the

build.properties

often contains references to old commit hashes, as if it is referring to stuff that has been cached somewhere

acceptable-scooter-37412

01/23/2017, 1:36 PM

the weirdness continues...if I insert some arbitrary

deploy_jar_rules

section to the BUILD stanza, it magically works

acceptable-scooter-37412

01/23/2017, 1:36 PM

even if it is something like

deploy_jar_rules=jar_rules(rules=[])

with no rules inside, the

build.properties

then contains what is expected

acceptable-scooter-37412

01/23/2017, 1:37 PM

BUT, it isn't any change to the BUILD stanza that works. So say I add a

resources

section, or a I add more

dependencies

, it reverts to faulty behaviour

acceptable-scooter-37412

01/23/2017, 1:39 PM

I am completely stumped, and not sure how best to arrive at a fix. (putting arbitrary

deploy_jar_rules=jar_rules(rules=[])

in the BUILD stanzas seems non-ideal)

acceptable-scooter-37412

01/23/2017, 1:39 PM

any insight, tips, pointers, would be super appreciated 🙂

high-advantage-47550

01/23/2017, 3:23 PM

@happy-kitchen-89482 — sorry, by re-running I mean on CI, potentially on two different machines. the command in this case is

compile myproject/src/main/scala

enough-analyst-54434

01/23/2017, 5:04 PM

@acceptable-scooter-37412 if I stop reading at "...if both are running the command while checked out on same branch" I already have questions that all need the source code of your plugin. Basically - getting different answers about git commit hashes back indicates your plugin is attempting to use invalidation or caching or both and running into issues there. Is the source for the plugin public and if not can you make it so?

billions-airport-86951

01/23/2017, 5:11 PM

is there a reason that the Cobertura plugin runs with slf4j? I've removed it in a local build of pants and I don't seem to get any errors - having multiple slf4j bindings on the classpath is failing some of my tests 😞

enough-analyst-54434

01/23/2017, 5:11 PM

@high-advantage-47550 what Benjy says is true, but if somehow the cache is being consulted despite invalidation checks, one important bit is the cache writes are async and can even fail silently - its not obvious, but the async cache write is here: https://github.com/pantsbuild/pants/blob/master/src/python/pants/task/task.py#L549-L555

enough-analyst-54434

01/23/2017, 5:12 PM

@billions-airport-86951 no reason - you may be able to shade it out

billions-airport-86951

01/23/2017, 5:14 PM

its explicitly included:

Copy code

register_jvm_tool(register,
                      'cobertura-instrument',
                      classpath=[
                        cobertura_jar(),
                        slf4j_jar
                      ])

Can I shade it out with config or do I need to submit a PR to remove it?

enough-analyst-54434

01/23/2017, 5:14 PM

This would be PR territory. Just a sec - pulling up the RB to see if this was discussed.

enough-analyst-54434

01/23/2017, 5:18 PM

OK - no discussion on the RB and yet this is definitely a bug - we can't be forcing slf4j impl's on a user classpath unless we shade. So definitely at least worth an issue and if you have bandwidth to try a fix - even better.