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.
In this commit, we create the initial CODEOWNERS file for `lnd`. This
file is a new-ish feature of Github that allows the maintains of a
project to define the individuals who are deemed to be experts of a
particular section of the codebase. Automated review assignment systems
can then use this file to generate required reviewers for a section of
the project. The CODEOWNERS file isn't meant to be a strict guideline,
but instead can be used to ease the burden of finding reviewers for a
particular section of the codebase.
It's also possible to enforce that the CODEOWNERS for a particular
file/package sign-off on relevant changes, thereby blocking review
unless they're involved. However, for now we'll simply use it to guide
the review assignment project, leaving creating blocking review
constraints until a later point if deemed useful.
- Update Go version 1.11 to 1.12
- Fix broken link in GitHub PR template
- Fix inconsistent number of spaces after checkbox
- Add proper link to "Ideal Git Commit structure"
