thanks, that would help.

there is another potentially salient patch in there: 6a43414801b44ae953a2a45af12c084660e2f7eb

k. testing… this could take up to 20mins.

first run with 1.2.0 worked, sigh. deleted .pants.d and running again, seems that jdbc and hadoop-common are cache misses multiple times… this run also seems like it will pass. i need to create a legit PR and have the CI obliterate the work directory.

looks like the PR is going to pass with 1.2.0.

is there a way to create a centralized pants daemon for the entire CI agent?

also, i’m interested in the reasoning for forking zinc - https://github.com/pantsbuild/pants/tree/master/zinc

no we don't use the forked zinc any more, used to

that is dead code, probably should be cleaned up to avoid confusion

well i was thinking about https://github.com/pantsbuild/zincutils, that was dead code

still https://github.com/pantsbuild/pants/tree/master/zinc is not forked zinc, it is a thin wrapper over zinc

ok.. cool. i saw that and panicked a bit… will get back to you guys in the AM regarding 1.3.0 dev7

hi guys, we’re seeing a recent uptick in “database is locked” from the statsdbfactory (particularly on Jenkins boxes) - is there something we should be doing in CI to improve the parallelability?

it seems to be coming from

run_tracker

after a pants run has reported [SUCCESS] - it feels a bit weird for the stats writing failing to change the return value

@fast-megabyte-33579 yea we ran into that, the default location is in ~/.cache that could be shared on ci. we change to place statsdb under buildroot in our ini

👍 seems like a simple change in our pants.ini override file

v. nice, thanks

also minor add

.statsdb.sqlite

to

.gitignore

wonder if we should make that the default

probably should, looking at other stuff under

~/.cache

this seems to more likely cause contentions

Hey guys, my folks are getting some weird ivy errors (have been for a while now trying to get to bottom of it). we have bit of non-standardness in that we store our internal company jars in S3 and use a customer resolver (https://github.com/ActionIQ/s3-ivy-resolver) to fetch those. this is how we did things back in maven/sbt times so we ported it over. anyways, to make it work with pants here’s what we use: https://gist.github.com/nitay/a29582f3c558d85a37625cc375923dfe The problem we’re seeing is that once in a while

resolve.ivy

fails with odd cannot find jar xyz errors (even though those jars are definitely there), like https://gist.github.com/nitay/6a57654c1fc95618a56969c9b6f31822 but intermittently. The only thing that seems to fix it (and not clear if always fixes it) is setting

use_nailgun: False

as you see in snippet. I also tried not doing that but using

./pants ng-killall

but that doesn’t fix it. In S3 we store our jars, which have their own deps most of which come from maven-central. Something in that flow mixed with the various caching of pants/nailgun/etc seems to intermittently fail but its not clear to me why/where

@happy-kitchen-89482 @ancient-stone-50795 https://groups.google.com/forum/#!msg/pants-devel/rmbnLDQxtjg/V3z9Q3CPPcoJ seems somewhat related ^

@mysterious-action-44812 My guess is that you are seeing flakiness in connecting or downloading from maven central. Our solution is to use an internal m2 proxy to cache stuff from maven central instead of always going out to maven central (we use Nexus)

Also, we have nailguns killed at the end of each run:

# kill_nailgins: Kill all naliguns at the end of each pants run
kill_nailguns: True

@witty-crayon-22786 @full-kilobyte-93429 was able to sustain a failed state with 1.2.0, then tried 1.3.0.dev8 and it worked.

nice. is that definitive, or just lucky?

i’m 70% confident the issue has been resolved, will continue to run tests under different conditions. i took a look at the significant zinc modifications in 1.3.x and the fingerprinting looks solid (have not stepped through it yet).

@ancient-stone-50795 it only happens when using our S3 jars though, it fails on the maven jars as dependencies of our jars

hmm — i’m trying to use the

webpack-dev-server

package (which watches files, rebuilds in-memory, and serves them over http) — but watching files won’t work because the actually executed files are in

.pants.d

. is there any good solution for this? should i look at forking the contrib/node module and adding some kind of watch mode with the watchman infra?