https://pantsbuild.org/ logo
Powered by
#general
  • l

    limited-country-20626

    01/11/2017, 7:07 PM
    It doesn't look that odious, but we are going to sit on 1.2.1 for a bit so you should continue as you feel fit
  • f

    full-kilobyte-93429

    01/11/2017, 7:08 PM
    ok, cool, i expect little/no work from this minor bump
  • l

    limited-country-20626

    01/11/2017, 7:08 PM
    We really needed to consume a 1.2.0, it was blocking our ability to push out opensource. But we are very happy with 1.2.1, now that we finally consumed it : )
  • w

    witty-crayon-22786

    01/11/2017, 7:25 PM
    @broad-london-44229 : if you're trying to add a task that "depends on compile", you'd want to depend on the products generated by the compile (
    runtime_classpath
    , iirc). see http://www.pantsbuild.org/dev_tasks.html#product_types-and-require_data-why-test-comes-after-compile
    👍 1
  • w

    witty-crayon-22786

    01/11/2017, 7:26 PM
    and actually, you might want to depend on 
    consolidated_classpath
    (which is full of jars), now that i think about it
  • w

    witty-crayon-22786

    01/11/2017, 7:27 PM
    alternatively, if you just need to add stuff to a bundle, or to a fatjar, you can probably do that by just adding resources
  • w

    witty-crayon-22786

    01/11/2017, 7:28 PM
    @clean-fish-15260 : one way to minimize that type of error in CI would be to disable incremental compilation there
  • w

    witty-crayon-22786

    01/11/2017, 7:28 PM
    Copy code
    compile.zinc.incremental = True (from HARDCODED)
compile.zinc.incremental_caching = False (from HARDCODED)
  • w

    witty-crayon-22786

    01/11/2017, 7:29 PM
    incremental outputs are not cached by default, so disabling incremental compilation can help to write more to the cache too.
  • w

    witty-crayon-22786

    01/11/2017, 7:29 PM
    but it is odd that your users don't see it locally as well. i don't see anything obvious in your options.
  • b

    brash-oxygen-26029

    01/11/2017, 8:32 PM
    I'm having trouble getting tests to pass for a PR build https://github.com/pantsbuild/pants/pull/4163. The last two integration test jobs are failing with ```
  • b

    brash-oxygen-26029

    01/11/2017, 8:32 PM
    No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received The build has been terminated
  • b

    brash-oxygen-26029

    01/11/2017, 8:32 PM
    ```
  • b

    brash-oxygen-26029

    01/11/2017, 8:33 PM
    I've run both parts locally and they pass.
  • b

    brash-oxygen-26029

    01/11/2017, 8:33 PM
    Is it possible we need to set a 
    travis_wait
    method as specified from the URL? Or am I missing something else?
  • b

    brash-oxygen-26029

    01/11/2017, 8:34 PM
    FWIW these tests were passing in CI for the PR before I rebased off of latest master
  • w

    witty-crayon-22786

    01/11/2017, 8:41 PM
    @brash-oxygen-26029 : do they take a long time to run locally? maybe splitting them would help
  • b

    brash-oxygen-26029

    01/11/2017, 8:43 PM
    ===== 69 passed, 2 skipped in 683.20 seconds =====
    for the second one and 
    ===== 70 passed, 1 skipped in 780.63 seconds =====
    for the first failing one locally
  • w

    witty-crayon-22786

    01/11/2017, 8:43 PM
    hm. might need another integration test shard then
  • b

    brash-oxygen-26029

    01/11/2017, 8:43 PM
    That doesn't seem too long. At least compared to the other build shards
  • w

    witty-crayon-22786

    01/11/2017, 8:43 PM
    ...oh. "No output has been received"
  • w

    witty-crayon-22786

    01/11/2017, 8:44 PM
    so it's not about the total runtime, it's just about spending a lot of time in the one test
  • w

    witty-crayon-22786

    01/11/2017, 8:44 PM
    tests/python/pants_test/projects/test_testprojects_integration.py
    is notoriously large
  • w

    witty-crayon-22786

    01/11/2017, 8:44 PM
    might need to split it a bit
  • b

    brash-oxygen-26029

    01/11/2017, 8:46 PM
    Ok. Looks like there is already this test in 
    test_testprojects_integration.py
    for the same reason # This is a special case that we split into 2 tests instead of using ensure_engine. # The reason is the original test with ensure_engine takes more than 10 minutes in travis ci, # which will cause travis to terminate the build. By spliting, each test finishes in less than # 10 min. def test_testprojects_v2_engine(self): with environment_as(PANTS_ENABLE_V2_ENGINE='true'): self.test_testprojects()
  • b

    brash-oxygen-26029

    01/11/2017, 8:47 PM
    Or should we run it with 
    travis_wait
    method above?
  • w

    witty-crayon-22786

    01/11/2017, 8:48 PM
    timeouts are a good thing in general, so i would think that rather than disabling them splitting further would be better.
  • b

    brash-oxygen-26029

    01/11/2017, 8:49 PM
  • w

    witty-crayon-22786

    01/11/2017, 8:50 PM
    i'm fine either way. but if that file doesn't already mention a ticket, we should open one about finding a more sustainable way to split it.
  • b

    brash-oxygen-26029

    01/11/2017, 8:54 PM
    I'll try 
    travis_wait
    , if that doesn't work I'll try splitting it.
1...159015911592...2420Latest