Release builds

The published builds of bs are made by two GitHub Actions workflows, both run by hand: one tags each repository with a version, and one builds, signs and publishes the server from those tags.

1. Version tags#

Each of libbitcoin-system, -database, -network, -node and -server has a version-tag.yml workflow. Its inputs are a branch (master by default), a tag description and a tag suffix. It computes the version from the branch:

The tag is v<major>.<minor>.<patch> followed by the suffix, and is created as an annotated tag and pushed. The workflow fails if the tag already exists.

2. Build to Release#

manual-release.yml, in libbitcoin-server, takes a tag for each of the five repositories, and an optional suffix for the release title. Its four jobs run in order.

2.1 validate-tags#

Checks out each repository at its tag, and fails unless each tag exists as a tag (not a branch or commit).

2.2 build-candidates#

One job for each build, all from the same tags. Each checks out the five repositories side by side and builds bs with the server's install script, using the local sources (--build-use-local-src) and skipping the tests (--build-skip-tests):

The same job also builds the selector of libbitcoin-system, which reports the processor's features, for the packages that choose a variant at install (Packaging):

Every x64 build assumes AVX2 and SSE4.1 (x86-64-v3) as the baseline of its architecture.

Linux builds link the C++ and GCC runtimes statically (-static-libstdc++ -static-libgcc); musl builds also link the C library statically (--static). Windows builds end in .exe.

After the build, each job:

1. copies the program to its build name,
2. removes any embedded RPATH/RUNPATH (patchelf, glibc Linux builds),
3. separates its debug symbols from the binary and strips it,
4. runs --version and --hardware, and shows the linkage (ldd, readelf -d, otool -L),
5. uploads the build and its symbols as artifacts, kept for one day.

Every build is compiled with debug information (-g, and a PDB with MSVC), and its symbols are published beside it:

2.3 sign#

Runs in the release environment, which holds the signing key and its passphrase as secrets, and does not start until a maintainer approves it. It downloads every build, imports the key into a temporary keyring, and writes a detached, armored signature beside each build and symbols file (<file>.asc). It then deletes the key and the keyring, imports the public key, and fails unless every signature verifies as a good signature. The builds, symbols and signatures are uploaded as one artifact.

2.4 publish#

Also in the release environment, and also waits for approval. It creates a release at the server tag (with the suffix, if any), as a draft prerelease, with the builds, their symbols and the signatures as its assets. Existing assets are not overwritten. The release notes link the tag of each of the five repositories it was built from, and show the public key that signed it.

The draft is public once a maintainer publishes it.