Merge #15693: travis: Switch to ubuntu keyserver to avoid timeouts

fa2056af1c travis: Properly cache and error on timeout (MarcoFalke)
fa36a333ee travis: Switch to ubuntu keyserver to avoid timeouts (MarcoFalke)

Pull request description:

  The other keyserver is consistently timing out on travis: https://travis-ci.org/bitcoin/bitcoin/jobs/512689710#L405

  Attempt to fix it by using a different server.

  Also:
  * fixes #15372
  * fixes #15738

ACKs for commit fa2056:
  ryanofsky:
    utACK fa2056af1c71aded3a821a07ec4de71c4be0bca3. All good changes (changing keyserver, getting rid of keyserver while loop, clarifying travis error, moving travis documentation to code comment).

Tree-SHA512: ac8436616ecfee0ed579114e19f03c53ceb688fbcd95a60cffe8f15b4e569772a6ba673f353bbd789e79fe27fc5626c77fab4086768844dd51e0c6c108b52fb2
This commit is contained in:
MarcoFalke 2019-04-09 11:17:25 -04:00 committed by UdjinM6
parent b804c7d7fe
commit 27b5d68562
4 changed files with 17 additions and 45 deletions

View File

@ -2,6 +2,21 @@
# - sudo/dist/group are set so as to get Blue Box VMs, necessary for [loopback]
# IPv6 support
# The test build matrix (stage: test) is constructed to test a wide range of
# configurations, rather than a single pass/fail. This helps to catch build
# failures and logic errors that present on platforms other than the ones the
# author has tested.
#
# Some builders use the dependency-generator in `./depends`, rather than using
# apt-get to install build dependencies. This guarantees that the tester is
# using the same versions as Gitian, so the build results are nearly identical
# to what would be found in a final release.
#
# In order to avoid rebuilding all dependencies for each build, the binaries
# are cached and re-used when possible. Changes in the dependency-generator
# will trigger cache-invalidation and rebuilds as necessary.
#
dist: xenial
os: linux
@ -177,7 +192,7 @@ before_script:
# Build docker image only for develop branch of the main repo
- if [ "$TRAVIS_REPO_SLUG" != "dashpay/dash" -o "$TRAVIS_BRANCH" != "develop" -o "$TRAVIS_PULL_REQUEST" != "false" ]; then export DOCKER_BUILD="false"; echo DOCKER_BUILD=$DOCKER_BUILD; fi
# TODO: Check keys and signed commits
#- if [ "$TRAVIS_REPO_SLUG" = "dashpay/dash" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then while read LINE; do travis_retry gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys $LINE; done < contrib/verify-commits/trusted-keys; fi
#- if [ "$TRAVIS_REPO_SLUG" = "dashpay/dash" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then travis_retry gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys $(<contrib/verify-commits/trusted-keys); fi
#- if [ "$TRAVIS_REPO_SLUG" = "dashpay/dash" -a "$TRAVIS_EVENT_TYPE" = "cron" ]; then travis_wait 30 contrib/verify-commits/verify-commits.py; fi
after_script:
- echo $TRAVIS_COMMIT_RANGE

View File

@ -20,6 +20,6 @@ test/lint/lint-all.sh
if [ "$TRAVIS_REPO_SLUG" = "bitcoin/bitcoin" ] && [ "$TRAVIS_EVENT_TYPE" = "cron" ]; then
git log --merges --before="2 days ago" -1 --format='%H' > ./contrib/verify-commits/trusted-sha512-root-commit
while read -r LINE; do travis_retry gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys $LINE; done < contrib/verify-commits/trusted-keys &&
travis_retry gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys $(<contrib/verify-commits/trusted-keys) &&
./contrib/verify-commits/verify-commits.py --clean-merge=2;
fi

View File

@ -52,7 +52,6 @@ The Dash Core repo's [root README](/README.md) contains relevant information on
- Source Code Documentation ***TODO***
- [Translation Process](translation_process.md)
- [Translation Strings Policy](translation_strings_policy.md)
- [Travis CI](travis-ci.md)
- [JSON-RPC Interface](JSON-RPC-interface.md)
- [Unauthenticated REST Interface](REST-interface.md)
- [Shared Libraries](shared-libraries.md)

View File

@ -1,42 +0,0 @@
Travis CI
=========
Support for using travis-ci has been added in order to automate pull-testing.
See [travis-ci.org](https://travis-ci.org/) for more info
This procedure is different than the pull-tester that came before it in a few
ways.
There is nothing to administer. This is a major feature as it means
that builds have no local state. Because there is no ability to login to the
builders to install packages (tools, dependencies, etc), the entire build
procedure must instead be controlled by a declarative script `.travis.yml`.
This script declares each build configuration, creates virtual machines as
necessary, builds, then discards the virtual machines.
A build matrix is constructed to test a wide range of configurations, rather
than a single pass/fail. This helps to catch build failures and logic errors
that present on platforms other than the ones the author has tested. This
matrix is defined in the build script and can be changed at any time.
All builders use the dependency-generator in the [depends dir](/depends), rather than
using apt-get to install build dependencies. This guarantees that the tester
is using the same versions as Gitian, so the build results are nearly identical
to what would be found in a final release. However, this also means that builds
will fail if new dependencies are introduced without being added to the
dependency generator.
In order to avoid rebuilding all dependencies for each build, the binaries are
cached and re-used when possible. Changes in the dependency-generator will
trigger cache-invalidation and rebuilds as necessary.
These caches can be manually removed if necessary. This is one of the very few
manual operations that is possible with Travis, and it can be done by the
Dash Core committer via the Travis web interface.
In some cases, secure strings may be needed for hiding sensitive info such as
private keys or URLs. The travis client may be used to create these strings:
http://docs.travis-ci.com/user/encryption-keys/
For the details of the build descriptor, see the official docs:
http://docs.travis-ci.com/user/build-configuration/