Switch Travis to Trusty #7920

pull theuni wants to merge 6 commits into bitcoin:master from theuni:travis-trusty changing 5 files +90 −12
  1. theuni commented at 3:35 AM on April 21, 2016: member

    I worked with Travis to get the cache flag on my personal repo for testing, and I'm happy to report that all works great (after a day of churning builds).

    For some background: Travis has enabled caching for their new infrastructure, but the feature is brand new and not yet generally available. For now it requires a special flag (set on their end) on your repo. Once they're satisfied with its stability, the flag will be granted to everyone. Note that the flag comes with the caveat of invalidating all current caches. That's not a problem for us, other than slowing things down for a few hours. I was primarily worried about unintended side-effects of opting in, so I added it on my own repo for testing before requesting it here.

    If there's no reason to delay our move, I'll request the flag for this repo tomorrow (4/21).

    Once that's take care of, we can merge this for Trusty goodness. On the day that Xenial is scheduled to be released :p.

    Next step is c++11, which should be painless to enable now.

    Note that this includes #7792, otherwise the OSX build fails. @laanwj I'm happy to rebase if you'd prefer to merge that first.

  2. theuni commented at 4:52 AM on April 21, 2016: member

    Note that the build failed because we currently have a (different) special flag on our repo that force-routes us to the legacy infrastructure for caching. This change will disable that in favor of the new testing flag.

    (It may sound convoluted, but this change moves us one step closer towards being a normal repo. Once the caching feature is out of beta, there will be nothing special about us.)

  3. in .travis.yml:None in 7797435ca9 outdated
      45 |      - compiler: ": Win64"
      46 | -      env: HOST=x86_64-w64-mingw32 PPA="ppa:ubuntu-wine/ppa" PACKAGES="nsis gcc-mingw-w64-x86-64 g++-mingw-w64-x86-64 binutils-mingw-w64-x86-64 mingw-w64-dev wine1.7 bc" RUN_TESTS=true GOAL="deploy" BITCOIN_CONFIG="--enable-gui --enable-reduce-exports" MAKEJOBS="-j2"
      47 | +      env: HOST=x86_64-w64-mingw32 DPKG_ADD_ARCH="i386" PACKAGES="nsis g++-mingw-w64-x86-64 wine1.6 bc" RUN_TESTS=true GOAL="deploy" BITCOIN_CONFIG="--enable-gui --enable-reduce-exports" MAKEJOBS="-j2"
      48 |      - compiler: ": bitcoind"
      49 | -      env: HOST=x86_64-unknown-linux-gnu PACKAGES="bc python-zmq" PPA="ppa:chris-lea/zeromq" DEP_OPTS="NO_QT=1 NO_UPNP=1 DEBUG=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --enable-glibc-back-compat --enable-reduce-exports CPPFLAGS=-DDEBUG_LOCKORDER"
      50 | +      env: HOST=x86_64-unknown-linux-gnu PACKAGES="bc python-zmq python3-zmq" DEP_OPTS="NO_QT=1 NO_UPNP=1 DEBUG=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --enable-glibc-back-compat --enable-reduce-exports CPPFLAGS=-DDEBUG_LOCKORDER"
    


    MarcoFalke commented at 6:02 AM on April 21, 2016:

    Mind to share why the py2 and py3 packages of zmq are needed?


    MarcoFalke commented at 6:11 AM on April 21, 2016:

    @theuni Jup, let's keep it py2 only for now, if possible.


    theuni commented at 6:12 AM on April 21, 2016:

    Sure, will remove.

  4. MarcoFalke commented at 6:02 AM on April 21, 2016: member

    Awesome! Concept ACK!

  5. theuni commented at 6:08 AM on April 21, 2016: member

    @MarcoFalke Just for the sake of being future-proof. It only uses the python2 one at the moment, but I believe the (your?) intention is to move the rpc tests to python3. Just doing python2 for now is fine by me if that's what you'd prefer. I was just saving some future head-scratching when builds fail after the switch.

    Edit: Looking at the diff, I now see why you asked. Python was a headache when testing the migration from precise->trusty. I had a theory at one point that python3 was being forced for the rpc tests, which obviously turned out to not be the case. But I left it there since that's where we're headed.

  6. jonasschnelli added the label Build system on Apr 21, 2016
  7. gmaxwell commented at 5:14 PM on April 21, 2016: contributor

    Thanks for working on this.

  8. theuni force-pushed on Apr 21, 2016
  9. depends: mac deploy Py3 compatibility
    This fixes the gitian MacOSX build, it was broken in #7723.
    
    The patch to `native_mac_alias` should probably make it upstream.
    a6666b25c7
  10. travis: switch to Trusty 06fdffd222
  11. theuni commented at 5:41 PM on April 21, 2016: member

    Dropped the python3-zmq packages.

  12. theuni commented at 5:22 AM on April 23, 2016: member

    This was delayed because there's a little extra work needed in switching away from our old setup. ETA given from Travis is Monday.

  13. depends: enable pre-compiled headers for qt
    All trusty compilers work ok with this now, and it shaves a few minutes off of
    build time
    9267a47d86
  14. theuni force-pushed on Apr 26, 2016
  15. travis: drop MAKEJOBS=2 for windows compilers
    These were only in place because of the old precice mingw toolchain
    cf77fcdb1f
  16. theuni force-pushed on Apr 26, 2016
  17. theuni force-pushed on Apr 26, 2016
  18. travis: Don't disable writing ccache for pull-requests
    This was doing more harm than good. The original intention was to speed up
    builds, since a PR's ccache results will be thrown away anyway.
    
    However, each PR maintains its own cache, so disabling writes means that
    subsequent pushes don't benefit from the fresh cache. This is significant when
    (for example) many headers are touched in a PR, then the PR is updated. With
    this change, the updated PR will take advantage of the cache generated during
    the PR's previous build.
    174023c9b0
  19. travis: temporarily disable qt to avoid timeouts
    These builds take longer than they did on precise. Disable them now to keep
    things working, we can re-enable them after experimentation
    a33b7c9cb5
  20. theuni commented at 6:56 AM on April 26, 2016: member

    Ok, finally all green and cache-enabled.

    I disabled a few qt builds because they seem to take longer on this infrastructure than before. We can investigate and turn them back on asap.

    For now, until this is merged, PRs will be unusually slow, so it's probably best to go ahead with this now and work through the regressions.

  21. theuni renamed this:
    Do not merge yet: Switch Travis to Trusty
    Switch Travis to Trusty
    on Apr 26, 2016
  22. theuni commented at 7:22 AM on April 26, 2016: member

    To expand on the "PRs will be unusually slow" bit above:

    In removing the special bits from our repo, all caches have been invalidated. In theory, precise caches will be regenerated for subsequent PRs, but I'm nervous about that actually happening seamlessly on the deprecated platform.

    Even if it does work without issue, PRs will be slow until something is pushed into master. When a PR is created, the build cache is taken from its source branch (master), and copied into the PR. From there, the PR updates its own cache with each update.

    Right now we have no master cache, and no PR caches. So until there's something to pull from master, each PR will be rebuilding from scratch. Also, once we do pull the trigger on this, it will essentially invalidate all caches again, because all dependencies will be rebuilt for the new toolchains.

    tl;dr: Need to push something into master asap to avoid slow builds all day. May as well push this one, to avoid a repeat.

  23. MarcoFalke commented at 8:01 AM on April 26, 2016: member

    ACK on merging today.

  24. btcdrak commented at 11:15 AM on April 26, 2016: contributor

    ACK

  25. jonasschnelli commented at 11:18 AM on April 26, 2016: contributor

    ACK 174023c9b008fc02316bce972b0c1031de3feee3

  26. laanwj merged this on Apr 26, 2016
  27. laanwj closed this on Apr 26, 2016

  28. laanwj referenced this in commit c3e3cfb5d1 on Apr 26, 2016
  29. btcdrak commented at 11:27 AM on April 26, 2016: contributor

    @theuni Does this have to be backported as well?

  30. theuni commented at 3:59 PM on April 26, 2016: member

    @btcdrak Yes, the same issues apply to the other branches.

  31. MarcoFalke referenced this in commit 564aaa2cd0 on Apr 27, 2016
  32. braydonf referenced this in commit 43b9b4e74f on May 12, 2016
  33. braydonf referenced this in commit 6c44620e5a on Jun 2, 2016
  34. thokon00 referenced this in commit 83e80c4240 on Jun 28, 2016
  35. braydonf referenced this in commit d53ca25de5 on Oct 4, 2016
  36. sickpig referenced this in commit e57e3fe17c on Nov 14, 2016
  37. nomnombtc referenced this in commit f179536b7e on Nov 22, 2016
  38. codablock referenced this in commit 62d4a267e4 on Sep 16, 2017
  39. codablock referenced this in commit f1e57c1b93 on Sep 19, 2017
  40. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-13 21:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me