My key recently expired, in this commit, we update the keys to the new
refreshed version. These are the same keys, but with an expiry further
out.
Here's a clear sign of the latest Bitcoin block hash:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
000000000000000000013215ef7c32bc0427f388fc83623affe712f388
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQQpYhJoGq3wVlaize6QUl997uCthgUCaPi6xwAKCRCQUl997uCt
hpqNAQC5VnnbO6h/PjywGhU4LLRvH8SdgdDEMSc7xrtWd1vgPgD+IDrHqiAb+h38
ORBnUVJCVuZrPebtdnYXVQhII91eaw4=
=WRbl
-----END PGP SIGNATURE-----
In this commit, we add a call to "go clean -cache" after each platform
build in the release script to prevent the Go build cache from accumulating
unbounded disk space during the sequential 15-platform build process.
When building for multiple platforms in sequence with "go build -v", Go
creates intermediate build artifacts and caches compiled packages for each
target platform. While this caching improves build performance within a
single platform build, it causes the cache to grow substantially when
building for many platforms sequentially. With 15 different platform/
architecture combinations, each with their own cached artifacts, this
accumulation was contributing to the disk space exhaustion.
By clearing the build cache after each platform completes, we prevent this
unbounded growth while still allowing each individual platform build to
benefit from caching during its own compilation. The module cache is
preserved (we only clear the build cache), so dependencies don't need to be
re-downloaded between platforms.
On MacOS, the default BSD gzip produces a different output than the GNU gzip
on Linux. To ensure reproducible builds, we need to use GNU gzip.
This is similar to what we do to enforce GNU tar.
This script compares a release branch against a source branch
(e.g. master) to verify that all cherry-picked commits are
unmodified. It first attempts fast matching using normalized
patch hashes.
If no exact match is found, it falls back to a fuzzy matching
mechanism:
- Filters source commits by matching author and commit subject
- Compares normalized diffs using diff -u
- Selects the closest match based on line difference count
Useful for verifying cherry-picks or rebased commits during
release processes. Supports scan and compare limits for
performance.
Fixes#10093.
This commit removes some old signing keys that haven't been used to sign
in a while and have either expired or been revoked.
=== scripts/keys/arshbot.asc ===
KeyID: 90E00CCB1C74C611 Created: 2018-08-08 Expires: 2022-08-08 Revoked: NO
=== scripts/keys/Crypt-iQ.asc ===
KeyID: 118759E83439A9B1 Created: 2019-05-31 Expires: 2022-10-13 Revoked: NO
https://github.com/lightningdevkit/rust-lightning/pull/2029
This commit adjusts the backwards compatability test in 2 ways:
1) we first set up the bitcoin backend before waiting for our network
nodes to start. This is so that the nodes can sync to chain and
become fully active during the `wait_for_nodes` call.
2) Then, in the `wait_for_node` helper, we use the status server
response to determine if a node is ready instead of just waiting for
`GetInfo` to return a response. This is because waiting for
SERVER_ACTIVE is a more accurate signal that the node is ready to
receive RPC calls.
This commit adds a script to hunt flakes for a specific unit test with
trace logs. Also rename the make commands to make them more clear on
whether it's a unit test, itest, or paralleled itest.
Previously, we applied replacements to our schema definitions
to make them compatible with both SQLite and Postgres backends,
as the files were not fully compatible with either.
With this change, the only replacement required for SQLite has
been moved to the generator script. This adjustment ensures
compatibility by enabling auto-incrementing primary keys that
are treated as 64-bit integers by sqlc.
This commit adds a new flag to shuffle all the test cases before running
them so tests which require lots of blocks to be mined are less likely
to be run in the same tranch.
The other benefit is this approach provides a more efficient way to
figure which tests are broken since all the differnet backends are
running different tranches in their builds, we can identify more failed
tests in one push.
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.
