Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

looks like it error’d again, retried once more

<@U054MQUPL>: <https://github.com/pantsbuild/pants/issues/3773>

It is weird that as long as I add ensure_engine to tests/python/pants_test/projects/test_testprojects_integration.py, the travis ci will be stalled for more than 10 minutes and gives me error. locally this can pass in 2 minutes. Once I removed ensure_engine, it passes ci.

<@U0XUTHRPZ>: it may have something do with java 6

which you might not have on laptop, so some tests will be skipped

<@U0AALHEDR>: thanks! but it still feels weird. I think test_testprojects just runs all test targets in testprojects dir, with some hardcoded targets excluded. so I think ci and local should run the same targets?

no, except when test with both v1 and v2 engine, it hangs in ci

if you want to dig in, you can modify the .travis.yml to only run that test, and adding -ldebug and gradually more test targets to be excluded till the test passes. so you’d know which test caused the hang

<@U0XUTHRPZ>: so the way @ensure_engine works is that it takes the decorated function and runs it 2x with different environment variables. my guess would be that the double runtime cost of that (+ a potentially much slower v2 engine path) is exceeding the 10m travis output timeout.

on ci, a success run of that target takes around 6 minutes

so with ensure_engine it takes about 12 minutes

I wonder if there’s a pytest-compatible way to decorate a test and have it get split into two logical tests

so that it’d spit out two distinct `.`’s for each test

we can split, the other way is to use travis_wait

tho that still may not help us if we’re Nx slower for something thats 6m already

<https://docs.travis-ci.com/user/common-build-problems/#My-builds-are-timing-out>

yeah, i think in .travis.yaml, we do like travis_wait ./build-support/bin/ci.sh -x ${CI_FLAGS}?