Because we need to remain backwards compatible with the old
`dust-threshold` value we set the default value for
`channel-max-fee-exposure` later in the program flow. Given
the restrictions of the sample config check we need to exclude
this value from the check.
This commit updates `scripts/release.sh` to include a check for the
correct Go version before executing the release build. This ensures that
the release binaries are built with the specified Go version,
maintaining consistency and integrity for developer signatures.
Implemented linter scripts to ensure consistency of the Go version
specified in Dockerfiles and YAML files. These scripts verify that the
Go version used across these files is uniform, enhancing maintainability
and reducing configuration errors.
This commit also introduces a `GO_VERSION` Makefile variable to control
the Go version used throughout the project.
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.
