willcl-ark
commented at 5:46 PM on August 25, 2026:
member
Adds:
arm64-apple-darwin
x86_64-linux-gnu
x86_64-w64-mingw32
... Guix builds to CI as a stand-alone workflow.
Testing exposed that manifest_build.scm depends are invalidated by a subsequent manifest_gui.scm build, so the first commit here splits these inside of BASE_CACHE. This means they can both be cached and re-used.
The second commit exports the time machine commit which makes it easier to re-use in other scripts e.g. this CI workflow, but also places like an automated Guix substitute build server.
The final commit adds the new workflow and guix install shell snippet.
DrahtBot added the label Tests on Aug 25, 2026
DrahtBot
commented at 5:46 PM on August 25, 2026:
contributor
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
willcl-ark
commented at 5:59 PM on August 25, 2026:
member
I have configured two physically separate bitcoin core substitute servers for better availability (using this module. One server evaluates the guix closure and builds it. Then uses guix copy to copy store items to the second server via ssh.
We could include the default substitute servers (https://bordeaux.guix.gnu.orghttps://ci.guix.gnu.org), but this makes the CI runs noticeably slower as these (slow) servers are queried even when not used/selected. These servers obviously will never include our custom compilers, which are the slowest thing to build, too.
I tested a run with a single substitute server, shutting the server off part way through, and Guix didn't like that it thought a substitute should be available but then wasn't and so failed. I think our use of --fallback protects us in the case that no substitute servers are available before the run begins; everything is just rebuilt, but have not tested this yet.
willcl-ark force-pushed on Aug 26, 2026
willcl-ark marked this as ready for review on Aug 26, 2026
willcl-ark marked this as a draft on Aug 26, 2026
DrahtBot added the label CI failed on Aug 26, 2026
DrahtBot
commented at 8:45 AM on August 26, 2026:
contributor
<!--85328a0da195eb286784d51f73fa0af9-->
🚧 At least one of the CI tasks failed.
<sub>Task macOS native, fuzz: https://github.com/bitcoin/bitcoin/actions/runs/32941900565/job/98094394757</sub>
<sub>LLM reason (✨ experimental): CI failed because the rpc fuzz target returned exit code 1 due to an “Error processing input” during fuzzing.</sub>
<details><summary>Hints</summary>
Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:
Possibly due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the
affected test.
An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.
</details>
willcl-ark force-pushed on Aug 26, 2026
willcl-ark force-pushed on Aug 26, 2026
guix: cache GUI depends separately
The GUI manifest has a distinct Guix profile and consequently produces
different depends build IDs. Reusing one cache root lets each build replace
the other's archive, so a later build rebuilds depends.
Keep the artifacts in BASE_CACHE/BUILD and BASE_CACHE/GUI. This preserves both
variants in the existing master cache without changing depends.
efbb911021
guix: expose time-machine metadata
Make the pinned repository and commit available to callers that source the
Guix prelude.
A Bitcoin Core-specific substitute server only needs to build the
packages in the guix closure at a specific time machine commit. It does
not need to build the bitcoin core binary applications.
To facilitate extracting the time-machine commit, export it as a
variable, so substitute builders (and anybody else) can re-use it by
sourcing the prelude, instead of requiring error-prone command string parsing.
cc7ff13479
ci: add Guix build job
Run the single-host Guix build on pull requests and master pushes.
Use the Guix installer with a cached, verified bootstrap and retain
time-machine and depends caches to avoid repeated downloads and builds.
049c3d9319
dropme: save caches6b61a24174
dropme: only run guix workflowaa794bc1ae
willcl-ark force-pushed on Aug 26, 2026
willcl-ark
commented at 1:14 PM on August 26, 2026:
member
@hebasto I think that efbb91102107dd9e758c46b9cd51d7a1de28c38a (the first commit here) and #35929 are duplicating solutions in different ways.
I believe that #35929 is the neater solution, and still covers the multi-toolchain (dual Guix build) scenario via embedding the toolchain info in the build ID as part of:
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-08-26 19:51 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me