To make it less confusing what version of bitcoind is actually
installed, we now require the version to be specified as a command line
argument.
Because we tag the version in the docker image tag as bitcoin-core:XX
but the binary internally is located under /opt/bitcoin-XX.Y/, we
manually set Y to 0.
For some reason lnd doesn't properly shut down on some windows itests,
and the process still running makes it impossible to access its log
files.
So for the Windows integration test, we attempt to kill the whole
process tree once the process indicates it is done.
When one of the itest tranches fails, because we are running tests in
parallel, other tranches will still be running, which caused 7z to fail
at zipping the logs because race reads. This commit fixes it by making
sure we are waiting other tranches to finish before moving to zipping
and uploading the logs.
The new script perfoms the following checks on the sample-lnd.conf file:
1. Checks that all relevant options of lnd are included.
2. Verifies that defaults are labeled if there are also further examples.
3. Checks that all default values of lnd --help are mentioned correctly,
including empty defaults and booleans which are set to false by
default.
With the latest Golang Docker base image we are using the new gpg
version 2.4 is now being installed in the lnd Docker base image.
Apparently the expected value for the --keyring flag is just a file name
and not an absolute path. The path of the file is indicated either by
the $HOME environment variable or the --homedir flag. It looks like 2.4
now finally stopped supporting an absolute path in the --keyring flag
and we need to update our gpg command to make the script work again.
This should be backward compatible and still work on older versions of
gpg.
sqlc is a tool that generates fully type-safe idiomatic code from SQL.
The result is Go code can then used execute the queries in the database.
The noraml flow looks like:
- The developer write some sql that will update the schema in the
database: new tables, indices, etc
- The developer updates the set of queries that will use the new schema.
- `sqlc` generates type-safe interfaces to those queries.
- The developer can then write application code that calls the methods
generated by sqlc.
The tool configuration needs to live in the repo's root and its name is
`sqlc.yaml`.
LND will support out of the box sqlite and postgres. The sql code needs to
be (almost) the same for both engines, so we cannot use custom functions
like `ANY` in postgres.
The SQLC config file needs to define what is the target engine, we will
set postgres but the generated code can be executed by sqlite too.
In some specific cases, we will `match and replace` some sql lines to be
sure the table definitions are valid for the targeted engine.
Without this commit, PRs can fail to be merged via the merge queue, as
it'll fail with this error:
```
Run scripts/check-release-notes.sh
PR gh-readonly-queue didn't update release notes
Error: Process completed with exit code 1.
```
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.
With this commit we add a new restriction that checks that the
username in the signature file (manifest-<username>-<version>.sig) actually
does have a signing key and that the signature was created with that key.
The signature is only counted towards the minimum of 5 signatures if
that check is successful.
The changes in this commit were inspired by @kixunil in #5048.
Instead of importing the keys from Keybase, we add all the signing keys
to the repository. In addition to having the key file present each key's
ID must also be added to the verification script. This acts as a double
check that the correct key is added and makes a key change more
explicit.
This removes a vulnerability brought up by @Kixunil where both the lnd
and lncli binaries are executed to obtain their version before they have
been verified against the release. A malicious binary could have already
compromised the user's system before any of the checks had been
performed.
This commit it split out from the doc changes so that it can easily be
cherry-picked to master/0.13.0.
Without this commit, the build may break if a PR commit is created, as
that shows the `PR_NUMBER` field we parse out as "master", reflecting
that its a merge commit into the master branch.
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.
