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

Code Coverage & Benchmarks

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

Reviews

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #bitcoin-core/gui/896 (rpcconsole: display signet challenge by RandyMcMillan)
• #33620 (ci: Build ci_native_base image layer by maflcko)
• #33549 (ci: Add macOS cross task for arm64-apple-darwin by maflcko)
• #33514 (Clear out space on GHA jobs by willcl-ark)
• #33480 (ci: Turn CentOS config into Alpine musl config by maflcko)
• #33461 (ci: add Valgrind fuzz by fanquake)
• #33411 (ci: re-add Valgrind job to the CI by fanquake)
• #33142 (test: Run bench sanity checks in parallel with functional tests by maflcko)
• #31507 (build: Use clang-cl to build on Windows natively by hebasto)
• #31425 (RFC: Riscv bare metal CI job by TheCharlatan)
• #31410 (qa: Fix wallet_multiwallet.py by hebasto)
• #30595 (kernel: Introduce C header API by TheCharlatan)

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.

This will need permitting of the vmactions/freebsd-vm@v1 action in this repo.

A few comments for historical context:

• ci: Add FreeBSD GitHub Actions job #30164 (comment):

Not sure. What was the conclusion when GHA was added to the repo about enabling third party actions? IIRC it was unclear whether malicious or backdoored actions could compromise the repo, so the conclusion was to refrain from enabling them?

No objection to merging this, but I'd say unless it is clear that the repo can not be compromised, the action should not be enabled in this repo.

• ci: Add FreeBSD GitHub Actions job #30164 (comment):

• Albeit this seems fine (ci: Add FreeBSD GitHub Actions job #30164 (comment)), I think adding third-party actions should be limited as well.
• The third-party action has limited usage and exposure, so it may break from down under us, marking all CI runs red.

And just recently, #32513 has resolved #32508.

Yeah, this would be adding FreeBSD to add coverage for a single short-term compile time issue encountered there. Though, we'd still be missing OpenBSD/NetBSD coverage for stuff that is different on those platforms: #33128 (which seems like a long-standing issue that has existed since ever and no one bothered to report?)

🐙 This pull request conflicts with the target branch and needs rebase.

All vmactions/*-vm actions are now unconditionally cached using the repository's GHA quota.

Are you still working on this? If not, it can probably be closed

Yeah, from the above it seems like we are happy to just continue running the various *BSDs on nightly jobs. Will close for now.

All vmactions/*-vm actions are now unconditionally cached using the repository's GHA quota.

This is now configurable as of v1.3.8: https://github.com/vmactions/freebsd-vm/releases/tag/v1.3.8.

Does that mean this job is more viable to add now?

I'd say the opposite: I think we've learned that upstream can control at their will whether to cache something or not. I don't really understand the GHA ecosystem and I think it is horrible (#33562 (comment)), but I guess this is just me and maybe this is fine and we can enable this third-party single-person-maintainer action here?