#36082 ci: add Guix builds to CI

ReviewabilityReviewsAgreementSize
#36082 willcl-ark ci: add Guix builds to CIReady0Strong399 + 11 tests
  • Test Guix release binaries continuously in CI instead of waiting for manual builds or release time
  • Catch broken build manifests, codesign dependencies, and toolchain bugs before changes merge
  • Reviewing now is worthwhile with no blocking issues
  • Strong support for catching build and release issues early in CI (fanquake)
  • Concept approval without stated reasons (sedited)
  • Withdrew objections after author agreed to drop the problematic commit (hebasto)
  • Confirmed no objection after suggesting running tests on the binaries (maflcko)
  • 399 lines added or modified outside tests
  • 11 lines added or modified in tests
  • 2 lines removed in total
  • 7 files, 6 commits
Build and CI#8 of 56
P2 · test coverage
  • P2 because testing release packages continuously catches manifest and toolchain regressions early
  • Compiling in a release context catches issues currently missed and validates static toolchain work
Ranking notes
Test infrastructure#9 of 54
P2 · test coverage
  • P2 after comparing with the other PRs here (assessed alone as P3): Raised to P2 to match #35774: both close the gap of release-like binaries never being exercised by CI, and this one covers all three platforms plus codesign environments.
  • P3 because running the existing test suite on Guix binaries verifies release package behavior
  • Drives existing test machinery on release archives rather than expanding test framework capabilities
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Adds a GitHub Actions CI workflow that builds Bitcoin Core via Guix for Linux, Windows, and macOS, then runs unit and functional tests on the produced binaries across native runners. It verifies codesign environments prior to building, exports Guix time-machine metadata for cache re-use, and generates required test-runner config and sanitizer wrappers for unpacked release archives.

Problem: Release packages produced with Guix are not tested continuously in CI, leaving broken Guix environment manifests, codesign dependencies, and compiler/toolchain-specific bugs unnoticed until manual builds or release time.

Evidence of importance:

  • PR description: "Currently there is limited continuous testing of our exact release binaries... Many PRs also see Guix builds, although few of those probably run tests against the Guix-built binaries."
  • PR description: "...in the event that we start shipping some fully-static Linux builds (x64 and aarch64) as per current revision of #25573, our entire custom-built static glibc and compiler toolchain would be relatively untested by current CI jobs, and that would also be tested here."

Scope: Adds a standalone GitHub Actions workflow file along with helper scripts to install Guix and execute tests against extracted release archives.

Risk of a mistake: low (tests, build). CI workflows and test harness scripts change only test automation and build-time inspection without altering production binaries or consensus code.

Changed since the previous assessment: Added handling in the test runner script to generate `with_sanitizer_env.py` from its template to accommodate changes from merged PR #36308 when running tests against an unpacked release archive.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • author: rebase and push tidy-ups to top two commits 2026-10-02

Agreement

Strong

substantive support, no open objection (fanquake)

Thread notes: Added suggestion by maflcko to document motivation in the description, which willcl-ark addressed. The PR is waiting on the author to rebase and tidy up commits.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
hebasto (member)objection, approachfails to resolve duplicate builds of non-GUI packages per hostaccepted · hebasto agreed with author's proposal to drop the commitansweredyes2026-08-28: 'Unfortunately, it fails to resolve the second one: "2. All non-GUI packages are built twice per host (mostly relevant for non-Linux hosts)"'
Status from: 2026-08-28: hebasto: 'That sounds good to me.'
hebasto (member)objection, approachthe BASE_CACHE environment variable must be set explicitly for the commit to work as expectedaccepted · hebasto agreed with author's proposal to drop the commitansweredyes2026-08-28: 'for your commit to work as expected, the `BASE_CACHE` environment variable must be set explicitly'
Status from: 2026-08-28: hebasto: 'That sounds good to me.'
hebasto (member)suggestion, approachconsider suggestions regarding cache handling from PR #35929answered · author agreed to consider the suggestionansweredyes2026-08-28: 'Please also consider https://github.com/bitcoin/bitcoin/pull/35929#issuecomment-5451743557.'
Status from: 2026-08-28: willcl-ark: 'Thanks hebasto, that sounds reasonable to me'
maflcko (member)suggestion, usefulnessrun tests rather than only catching build errorsaccepted · maflcko confirmed having no objection to the pull and noted to feel free to ignore earlier remarksansweredyes2026-09-23: 'from the perspective of end-users a build error is harmless (there are no bugs if there is no binary :sweat_smile:), so it could make more sense to actually run the tests'
Status from: 2026-09-29: maflcko: 'Again, no objection to this pull'
maflcko (member)suggestion, maintenanceinclude the goal and motivation in the pull descriptionanswered · author updated the descriptionansweredyes2026-10-02: 'Mind including the goal/motivation in the pull description, so that it is easier to follow?'
Status from: 2026-10-02: willcl-ark: 'Thanks I've updated the description as you suggest.'

Support:

  • fanquake (member) (Concept ACK, 2026-09-15): Concept ACK [not substantive]
  • sedited (member) (Concept ACK, 2026-09-15): Concept ACK [not substantive]
  • fanquake (member) (2026-09-29): CI should catch build/release time issues before non-build changes merge; compiling in a release context catches issues currently missed

Participants:

  • hebasto (member, objection, 2 statements 2026-08-28 to 2026-08-28): objected that initial commit failed to prevent duplicate builds and required BASE_CACHE; accepted dropping it
  • fanquake (member, support, 2 statements 2026-09-15 to 2026-09-29): Concept ACK; argued in favor of testing release compilation in CI to catch issues early
  • sedited (member, support, 1 statements 2026-09-15 to 2026-09-15): Concept ACK
  • maflcko (member, neutral, 4 statements 2026-09-23 to 2026-10-02): suggested testing release binaries or using a nightly CI matrix; requested updating description with motivation; no objection to PR

Dependencies

Enables:

Files

13 lines under test/bench/ci.

  • .github/workflows/guix.yml +263/-0
  • .github/ci-guix-test.py +100/-0
  • .github/install-guix.sh +36/-0
  • contrib/guix/libexec/prelude.bash +5/-2
  • contrib/guix/libexec/build_linux.sh +2/-0
  • contrib/guix/libexec/build_macos.sh +2/-0
  • contrib/guix/libexec/build_win.sh +2/-0

Card

The short text the ranking pass compares across PRs.

Adds a GitHub Actions CI workflow that produces release packages with Guix for Linux, Windows, and macOS, and runs unit and functional tests on the resulting binaries using native runners. Currently, exact Guix release binaries and their codesigning environments are not continuously tested in CI, leaving packaging and toolchain breakages undetected until release engineering. The workflow checks codesigning environments and generates test harness configurations on the fly to test extracted binaries directly.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-30T01:12, confidence high, input hash 17be6cd77f8ddcfb
thread read through 2026-10-02 (18 statements), head 4bac9a480f
labels: Tests

Categories

Build and CI

P2 · test coverage

Testing Guix release packages continuously in CI addresses the release integrity gap where toolchain and manifest regressions currently go unnoticed until manual release time. Reviewers note this compilation in a release context catches issues currently missed and helps validate work like static toolchains (#25573).

Membership: Adds a GitHub Actions Guix CI workflow (`.github/workflows/guix.yml`) and modifies Guix build scripts in `contrib/guix/libexec/`.

Factors: security/stability 1, bug 0, performance 0, user value 0, leverage 2

Test infrastructure

P2 · test coverage (assessed alone as P3; Raised to P2 to match #35774: both close the gap of release-like binaries never being exercised by CI, and this one covers all three platforms plus codesign environments.)

Expands test suite execution to Guix-built release binaries by providing test runner harness wrappers. While valuable for verifying release package behavior, it drives existing test machinery rather than extending test framework capabilities.

Membership: Carries the Tests maintainer label and adds `.github/ci-guix-test.py` to generate test runner configurations and sanitizer wrappers for unpacked binaries.

Factors: security/stability 1, bug 0, performance 0, user value 0, leverage 2