ci: add Guix builds to CI #36006

Adds:

• arm64-apple-darwin
• x86_64-linux-gnu
• x86_64-w64-mingw32

... Guix builds to CI as a standalone 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.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36006.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #35855 (guix: update time-machine by fanquake)
• #35774 (ci: test cross-built macos arm64 binaries by willcl-ark)
• #35765 (depends: hash local source contents by willcl-ark)
• #33593 (guix: Use UCRT runtime for Windows release binaries by hebasto)
• #31507 (build: Use clang-cl to build on Windows natively by hebasto)
• #30343 (wallet, logging: Replace WalletLogPrintf() with LogInfo() by ryanofsky)
• #30342 (kernel, logging: Pass Logger instances to kernel objects by ryanofsky)
• #29700 (kernel, refactor: return error status on all fatal errors by ryanofsky)
• #26022 (Add util::ResultPtr class by ryanofsky)
• #25722 (refactor: Use util::Result class for wallet loading by ryanofsky)
• #19461 (multiprocess: Add bitcoin-gui -ipcconnect option by ryanofsky)
• #19460 (multiprocess: Add bitcoin-wallet -ipcconnect option by ryanofsky)
• #17783 (common: Disallow calling IsArgSet() on ALLOW_LIST options by ryanofsky)
• #17581 (refactor: Remove settings merge reverse precedence code by ryanofsky)
• #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)
• #17493 (util: Forbid ambiguous multiple assignments in config file by ryanofsky)

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-->

A full run with no caches and guix time machine sync completed in 38m 40s.

Testing exposed that manifest_build.scm depends are invalidated by a subsequent manifest_gui.scm build...

Have you seen #35929?

A cached build has completed in 23m 19s .

Based on the CPU usage, there is a lot of idel setup time still, even when using a substitute server:

<img width="2340" height="1428" alt="image" src="https://github.com/user-attachments/assets/a3feab3c-2aa4-47b8-bad1-da41ff542e67" />

So there is still some juice to squeeze. I may investigate using a pre-built docker container too (possibly based off this one) to see if we can cut down on some of that wasted runner time.

However overall, I think 20 - 40 minutes is pretty acceptable for a new CI job.

15m4s when dropping the slow https://ci.guix.gnu.org substitute server

15m4s when dropping the slow https://ci.guix.gnu.org/ substitute server

Could add a second HOST? Maybe arm64-apple-darwin, to get some LLVM toolchain coverage?

Seems fine to add this, but I fail to see the goal or motivation?

It would be good to list at least a single historic bug that this would catch.

Recall that the CI scripts already mirror the guix env, so any compile errors should be caught by the pre-existing CI scripts.

Also, any change to guix requires matching hashes on different arches, which this pull is not doing. So non-determinism or bugs such as #35855 (comment) are not caught either here.

Again, no objection to adding this, but I think it would be easier to review if there was a goal or motivation.

It would be good to list at least a single historic bug that this would catch.

It would have caught #33177 (broken in #32750, fixed in #33178).

Given the runtimes of 19m and 21m, this seems to be fast enough that you could add a Windows HOST as well.

Even with a populated depends cache, the native_libmultiprocess package is still building:

make: Entering directory '/bitcoin/depends'
Extracting native_libmultiprocess...
/home/runner/work/bitcoin/bitcoin/.guix-cache/depends-sources/src-ipc-libmultiprocess.tar: OK
Preprocessing native_libmultiprocess...
Configuring native_libmultiprocess...
<snip>
Building native_libmultiprocess...
<snip>
Postprocessing native_libmultiprocess...
Caching native_libmultiprocess...
copying packages: native_libmultiprocess native_capnp boost sqlite systemtap zeromq capnp

Could #35618 fix this?

Even with a populated depends cache, the native_libmultiprocess package is still building:

Yeah that is a shame. I'm not sure it happens every time though. Unsure of the cause...

Could #35618 fix this?

These are x64 Ubuntu runners, but perhaps I could cherry-pick that and test it out?

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task lint: https://github.com/bitcoin/bitcoin/actions/runs/32157463479/job/95778244301} _{LLM reason (✨ experimental): CI failed because the shell locale lint check reported a missing export LC_ALL=C in .github/install-guix.sh (lint-shell-locale.py).}

<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>

Could #35618 fix this?

It does indeed seem to fix it!

So it seems it would make sense to try and merge #35618 first. Then optionally split the first to commits out from here, before merging a Guix CI job.

What do you think @hebasto ?

So it seems it would make sense to try and merge #35618 first. Then optionally split the first to commits out from here, before merging a Guix CI job.

What do you think @hebasto ?

Sounds reasonable.