In this commit, we update Travis to start building against the newly
released go 1.13. Additionally, we'll now utilize the new `trimpath` to
the `go build` and `go install` commands. This new flag serves to remove
all file system paths from the compiled Go executable, which will make
our binaries more reproducible.
Before this commit, if for example the linter failed, then we would go
on to all the other tests rather than halting. We fix this by instead
chaining the relevant commands, and eliminating the LINT env variable
in the build matrix.
This commit sets the GOCACHE environment variable, and enables caching
on travis.
GOCACHE will tell the compiler (only go 1.10+) where to store build and
test artifacts. Caching this directory will significantly speed up
succeeding builds and test runs.
We also cache vendor/ as this will speed up the call to 'make dep'.
A few dependencies in the GOPATH are cached, as calls to 'go get' for
these will be sped up. Note that we don't cache the lnd directory, as it
will conflict with the changes in the PR being built.
This commit distributes the CI tests into 3 independend builds, by
splitting the integration test run and unit test coverage.
To better handle the extra cases, we define a build matrix with the
three build types (RACE and LINT, ITEST, COVER).
Instead of calling 'make travis' directly, we call each step. This lets us
better track how much time is spent on each.
Also note that we execute 'itest-only' instead of 'itest', and instead
execute the dependencies (btcd, build) manually first.
We explicitly set the ITEST environment variable, for readability, and
define a new COVER. This is currently true when ITEST=true to keep the
existing build configuration, but will later be configured to be
independent.
In this commit, we modify our build file to only lint under go 1.11. We
do this as there's been a breaking change in gofmt between go 1.10 and
go 1.11 that causes files which pass the linter under go 1.10, to fail
the linter under go 1.11. In the end, we only really need to lint using
one version of go.
In order to achieve this, we "unroll" the build matrix to enumerate each
version and the environment variables that it should be run with. We
then modify the Makefile to only include the lint directive if the
particular env variable is set ($(USE_LINT)). With these two changes,
we'll now only lint under go 1.11.
This commit modifies the travis build script, and our local test script
to ensure that the race condition builds are conducted in a parallel
build. After this commit two travis builds will be kicked off for each
push/commit: one that runs the race condition tests in isolation, and
another that runs the integration tests then the coverage tests.
In order to do the above cleanly, the integration tests are now guarded
behind a build flag. In order to run the integration tests, one now
needs to specify the `-tags rpctest` flag when running the `go test`
command.
Sticking with our tradition of tracking the two latest go releases,
we'll now build against Go 1.8 (which was recently released and Go
1.7.5).
The release of Go 1.8 is very attractive to the project as it includes
performance and GC improvements as well as the addition of more
profiling and race condition detection capabilities within the runtime.
This commit fixes some flakiness exhibited within the tests on Travis
due to the default behavior of the `go test` command to execute tests
amongst packages in parallel. Since many tests use the `rpctest`
package from `btcd`, many instances of `btcd` would be started at the
same time, with only one being able to grab the port and fully start
up. By forcing tests to be executed serially, this behavior should be
patched.
One downside is that builds on Travis will take longer. Therefore, this
may be a temporary fix a more fundamental fix within the `rpctest`
package is implemented.
This commit updates the previous travis CI config to pin against the
two latest golang versions, and perform installation via Glide.
Additionally, this should allow lnwallet’s integration tests to build
properly as the btcd binary will be available in the build process’
PATH.
