Use kvdb package v1.4.1. This update also forced the protobuf version to
be bumped which required `make rpc` to be run to update the generated
files. This also required a bump in the github pinned dependencies
config for the grpc and protobuf libs.
To avoid the problem where multiple jobs try to create the same cache
entry, we add the GitHub job ID to the cache key.
The two restore keys make it possible that a job can also restore a
cache entry from another job if none for the current job exist yet.
With this commit we allow the Go version that is set up to be
configurable and not dependent on a specific environment variable. This
will allow us to eventually extract the action into a tooling
repository.
For some reason we used to override the GOCACHE and GOPATH variables
earlier. This now causes the updated cache action not to pick up any
caches. As the overrides shouldn't be needed anymore, we remove them.
This commit adds a new flag `temptest` so we can run new and old tests
separately. This flag will be removed once the migration from old tests
to new tests is finished.
In this PR, we introduce a new Github work flow tool that should help us
keep better track fo reviewer load across the proejct. Ideally this can
also be used as a tool to help new PRs find a reviewer, and also for us
to better balance out review load, and keep track of how long it takes
to do PR turnaround.
With this commit we prepare for adding multiple issue templates to
GitHub that will be shown when the user clicks on the "New Issue" button
on GitHub.
The config.yml will also add a bunch of useful links to the page that
shows the different issue templates.
An example of how this template selection page looks like can be found
here: https://github.com/lightninglabs/lightning-terminal/issues/new/choose
As usual, we keep with the last two Go versions, which means the last
year of Go release (they release every 6 months or so).
This change means we can now use the type params (generics) in the
project!
This updates the list of tags used for `release` builds in the release
documentation. `peersrpc`, `kvdb_postgres`, and `kvdb_etcd` are now
automatically included in `make release` or `make release-install`
builds.
This commit re-adds the rolling `daily-testing-only` tag in addition to
the unique daily tag `daily-<YYYYmmdd>`.
A rolling `master` build was proposed but declined because this would
put an unnecessary burden on the build system (each run takes ~45 min)
Because we want to avoid local replace directives (as they make it easy
to screw up things for external applications that use lnd as a library
without us noticing), we're going to switch over to a new process.
See section "Use of Golang submodules" in the code contribution
guideline.
As is customary with new GitHub actions, they don't work on first
attempt if you don't test them *sigh*
We need to use a more recent version of golang than is pre-installed to
avoid the "unknown directive: retract" error message.
It turns out we were using the wrong matrix variable in the actual
make command and ran the same itest 6 times with no arguments, all
resulting in running the btcd test.
To avoid uploading too many files in individual requests, we zip them
first before uploading the zip itself.
With this commit we update the release template to download Roasbeef's
key from the git repository via GitHub.
We also update the key mentioned in the template to the new signing key.
[skip ci]
To reduce the likelyhood of the linter OOMing on the GitHub runner, we
exclude any generated code from being inspected and also tune the golang
garbage collector to be a bit more agressive.
The golang version always needs to be in sync between the go.mod, the PR
checklist and the installation instructions.
We also shorten the Pull Request template by removing everything that we
have a CI check for and just refer to those checks instead.
In this commit, we add a simple bash script to parse out the current PR
number from an environment variable in the GH actions context, and use
that to check to see if the PR has been referenced in the release notes
or not. This isn't 100% fool proof, but it should catch most of the
common cases.
The monitoring server still needs to be enabled using prometheus.enable,
so including this in the default build does not add an additional http
server unless the user opts in.
The golang build cache seems to only grow over time and is now causing
disk space issues on the release builder. Since the release build has to
build for targets that aren't built during other GH actions and our
releases are too far apart to be hitting the cache anyway we suspect the
cache doesn't actually help that much.
Removing it might mean the build takes a bit longer but at least won't
cause any problems with full virtual disks anymore.
Due to a misunderstanding of how the gpg command line options work, we
didn't actually create detached signatures because the --clear-sign
flag would overwrite that. We update our verification script to now only
download the detached signatures and verify them against the main
manifest file.
We also update the signing instructions.
Because we now build a docker image for the RPC compilation, we can save
some execution minutes if we run the mobile RPC and code compilation check in the
same step of the CI workflow.
To avoid leaking any sensitive information like Docker Hub credentials
because of compromised actions repositories, we use our own, vendored
actions for all steps that potentially touch sensitive information.
To enable building docker images for ARM64 platforms as well,
we just need to specify the desired target platforms and the Docker
Buildx service will do the job for us (provided the base images support
the given platforms, which is the case for golang).
Since it was added, we never maintained the file leading to decay in the
set of "actual" code owners. In practice, the current set up ends up
assign most reviews to 2 or so active contributors. I think the idea
itself is sound, but the current implementation leads to certain
reviewers being over-assigned PRs, which at times causes those PRs to
stagnate since pretty much every PR gets assigned to the same set of
people.
This commit adds another GitHub workflow that is activated for each
pushed tag. The release binaries are compiled from that tag for all
supported architectures. A new release in the GitHub repository is then
drafted for the tag and the finished binary packages are uploaded to
that release.
We add a GitHub workflow that is triggered whenever a new version tag is
pushed. It will trigger a docker image build for that version and
automatically push it to the specified repo.
Because we now have conditionally compiled code that depends on the
architecture it is built for, we want to make sure we can build all
architectures that we also release. Since GitHub builds are very fast,
we can easily do this instead of only compiling for certain select
architectures.
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.
To free up build in Travis, we decided to run the non-flaky parts of
the CI pipeline in GitHub Workflows/Actions only. The integration tests
on the other hand are removed from GitHub because individual actions
cannot be restarted there which caused us to restart the whole workflow
if one test was flaky.
This split should give us the best of both worlds: Fast run of small
checks, linting and unit tests with an easy overview of what failed in
the PR directly. And more free build slots on Travis to do more advanced
integration tests on other architectures and/or operating systems. And
the option to restart a single flaky integration test on Travis.
Checkout v1 has a known flake:
https://github.com/actions/checkout/issues/23#issuecomment-572688577.
For our linter to pass, we need to checkout our full history (default
depth is 1 commit). We could set fetch-depth, but we will eventually
move that depth past the linter's start point commit and need to
implement another fix. Indead, we add an extra step in our linter to
fetch full history so that the linter reference commit is found.
The continue-on-error was added to make sure the log files of the
failed itests would always be uploaded. But this has the side effect
of marking the whole job successful, even if the itest job itself
failed. The failure condition in the log file steps already solve
that, so the continue-on-error is not needed anymore.
