2016-06-09 01:12:13 +03:00
|
|
|
language: go
|
2018-10-11 11:31:05 +03:00
|
|
|
cache:
|
|
|
|
directories:
|
2020-03-13 21:03:00 +03:00
|
|
|
- ~/bitcoin/bitcoin-0.19.1/bin
|
2019-05-23 01:24:40 +03:00
|
|
|
- $DOWNLOAD_CACHE
|
2018-10-11 11:31:05 +03:00
|
|
|
- $GOCACHE
|
2018-11-29 04:18:21 +03:00
|
|
|
- $GOPATH/pkg/mod
|
2018-10-11 11:31:05 +03:00
|
|
|
- $GOPATH/src/github.com/btcsuite
|
|
|
|
- $GOPATH/src/github.com/golang
|
2019-05-23 01:24:40 +03:00
|
|
|
- $GOPATH/src/github.com/grpc-ecosystem
|
2018-10-11 11:31:05 +03:00
|
|
|
- $GOPATH/src/gopkg.in/alecthomas
|
2019-05-23 01:24:40 +03:00
|
|
|
- $GOPATH/src/google.golang.org
|
2018-10-11 11:31:05 +03:00
|
|
|
|
2020-02-20 22:18:43 +03:00
|
|
|
# Remove Travis' default flag --depth=50 from the git clone command to make sure
|
|
|
|
# we have the whole git history, including the commit we lint against.
|
|
|
|
git:
|
|
|
|
depth: false
|
|
|
|
|
2018-11-16 13:08:16 +03:00
|
|
|
go:
|
2020-02-26 21:33:53 +03:00
|
|
|
- "1.14.x"
|
2018-11-16 13:08:16 +03:00
|
|
|
|
|
|
|
env:
|
2018-10-11 11:31:05 +03:00
|
|
|
global:
|
|
|
|
- GOCACHE=$HOME/.go-build
|
2019-05-23 01:24:40 +03:00
|
|
|
- DOWNLOAD_CACHE=$HOME/download_cache
|
2018-10-11 11:31:05 +03:00
|
|
|
|
2018-01-17 19:07:31 +03:00
|
|
|
sudo: required
|
2018-10-11 11:31:05 +03:00
|
|
|
|
2019-05-23 01:24:40 +03:00
|
|
|
addons:
|
|
|
|
apt:
|
|
|
|
packages:
|
|
|
|
- clang-format
|
|
|
|
|
|
|
|
before_script:
|
|
|
|
- bash ./scripts/install_travis_proto.sh
|
|
|
|
- bash ./scripts/install_bitcoind.sh
|
travis: staged travis builds
This PR introduces staging to our travis pipeline. Currently all
instances perform:
- compilation of lnd
- linting
- compilation and installation of btcd binaries
- installation of bitcoind binaries
In total this adds about 3 minutes to each of our 5 instances, resulting in
roughly 12 minutes of redundant execution time. Additionally, if if a build
fails to compile or lint we detect this 5 separate times, consuming precious
instances from other builds.
We alleviate this by adding an initial Build phase, which runs a single
instance performing the actions above. This has the benefit of quickly sanity
checking the pr before moving on to the more expensive unit or integration test
suites, and failing faster for common mistakes. It also warms up the build
caches for the Test stage in one fell swoop.
For instance, if 5 people push changes at the same time, they can all get
immediate feedback regarding compilation or linting issues, and potentially
save hours waiting for other people's test to finish or fail before finding out
they had a spelling error. This doesn't alleviate all possible issues, e.g. the
5 instances may already be consumed by test suites, but it does make a sizable
step towards minimizing time-to-failure in common scenarios.
2019-12-05 06:53:20 +03:00
|
|
|
|
|
|
|
jobs:
|
|
|
|
include:
|
|
|
|
- stage: Build
|
2019-05-23 01:24:40 +03:00
|
|
|
script:
|
|
|
|
- make rpc-check
|
|
|
|
- make unit pkg=... case=_NONE_
|
2020-03-28 12:39:17 +03:00
|
|
|
- make lint workers=1
|
2019-05-23 01:24:40 +03:00
|
|
|
- make btcd
|
2020-04-21 11:48:07 +03:00
|
|
|
- make release sys=windows-amd64
|
2020-07-15 16:37:02 +03:00
|
|
|
- make mobile-rpc
|
|
|
|
- go build --tags="mobile" ./mobile
|
travis: staged travis builds
This PR introduces staging to our travis pipeline. Currently all
instances perform:
- compilation of lnd
- linting
- compilation and installation of btcd binaries
- installation of bitcoind binaries
In total this adds about 3 minutes to each of our 5 instances, resulting in
roughly 12 minutes of redundant execution time. Additionally, if if a build
fails to compile or lint we detect this 5 separate times, consuming precious
instances from other builds.
We alleviate this by adding an initial Build phase, which runs a single
instance performing the actions above. This has the benefit of quickly sanity
checking the pr before moving on to the more expensive unit or integration test
suites, and failing faster for common mistakes. It also warms up the build
caches for the Test stage in one fell swoop.
For instance, if 5 people push changes at the same time, they can all get
immediate feedback regarding compilation or linting issues, and potentially
save hours waiting for other people's test to finish or fail before finding out
they had a spelling error. This doesn't alleviate all possible issues, e.g. the
5 instances may already be consumed by test suites, but it does make a sizable
step towards minimizing time-to-failure in common scenarios.
2019-12-05 06:53:20 +03:00
|
|
|
- stage: Test
|
|
|
|
script: make travis-cover
|
|
|
|
name: Unit Cover
|
|
|
|
- script: make travis-race
|
|
|
|
name: Unit Race
|
|
|
|
- script: make itest
|
|
|
|
name: Btcd Integration
|
|
|
|
- script: make itest backend=bitcoind
|
|
|
|
name: Bitcoind Integration
|
|
|
|
- script: make itest backend=neutrino
|
|
|
|
name: Neutrino Integration
|
2018-10-11 11:31:05 +03:00
|
|
|
|
2017-10-18 01:42:22 +03:00
|
|
|
after_script:
|
2019-06-05 00:51:25 +03:00
|
|
|
- LOG_FILES=./lntest/itest/*.log
|
|
|
|
- echo "Uploading to termbin.com..." && find $LOG_FILES | xargs -I{} sh -c "cat {} | nc termbin.com 9999 | xargs -r0 printf '{} uploaded to %s'"
|
|
|
|
- echo "Uploading to file.io..." && tar -zcvO $LOG_FILES | curl -s -F 'file=@-;filename=logs.tar.gz' https://file.io | xargs -r0 printf 'logs.tar.gz uploaded to %s\n'
|