To fix an issue where the golang version would be picked up from the
host system if the docker-release command was used, we switch over to
using make inside of the container as well instead of feeding the
parameters into the release script manually.
We only pass in the flags that we might actually want to overwrite.
To fix an issue where the vendor.tar.gz in a release build had a
different hash if the mobile RPC stubs were in the mobile/ folder, we
clean those out first.
The culprit was the `google.golang.org/grpc/test/bufconn` package which
is currently only used in the mobile RPC stubs and nowhere else.
Therefore the vendor/module.txt was different when vendoring with the
generated mobile RPC stubs being around.
Now that we have a base docker image that has all our RPC compilation
dependencies installed, we can also run the mobile RPC compilation
there. This removes the need to install falafel and goimports on the
local machine.
This commit aims to make it easier for developers to compile our
protobuf definitions. They now only need to have docker installed
instead of a whole set of binaries and libraries all pinned to very
specific versions.
We add a new make goal called release-install that creates the same
reproducible binaries as the release script would create, but only for
the current OS/architecture. It then installs those binaries to the
system's GOBIN directory.
To allow easy verification of individual binaries (instead of just the
packag tarballs/zips), we also add the hashes of lnd and lncli binaries
to the manifest. We do the same in the docker build.
To make sure we build the exact version of btcd that is referenced in
the project's go.mod file and to not overwrite any binary the user might
already have installed on the system, we compile btcd into an explicit
file in the itest directory.
This should also speed up invocations of "make itest-only" because the
test harness doesn't always compile btcd on its own.
We also fix a bug with the version parsing where adding a "replace"
directive in the go.mod would result in the awk commands to extract the
wrong version. Because we no longer use the DEPGET goal to build and
install btcd, using a replace directive now actually works for itests.
To remove the need to have an extra make goal for the Windows itests, we
instead add the flag windows=1 that sets the make variable EXEC_SUFFIX
to properly add the ".exe" suffix to all executable names.
To make the Makefile a bit easier to understand, we remove the implicit
ITEST goal/command variable and switch all itest execution over to
explicit goals in the main Makefile.
We add a GitHub action to our workflow that makes sure all command line
flags of lnd that are available with the default build tags are
contained in the sample-lnd.conf file.
Because this script is now run from the main Makefile, it is more
suitable to be located in the main scripts folder where the other
build related scripts reside.
There are different versions of clang-format being installed on
different versions of ubuntu that apparently produce different
results when formatting the proto files. This is likely too much
of a hurdle for new contributors to also manually install the
correct version of a command line tool just to format stuff.
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.
Conner Fromknecht