ci: add Chimera Linux LTO config

fanquake commented at 4:41 pm on January 27, 2026: member

Adds a CI config based on using Chimera Linux. This might be interesting for any of the following:

Chimera is based on LLVM & musl libc - we test both of these in isolation, but not together.
No GNU components. I don’t think we have an existing Linux CI job that doesn’t have a gcc/stdlibc++ install. This exercises the depends logic for a fully LLVM/Clang/lld only build, including building the native tools (related to #33902).
We don’t currently have a job with LTO enabled (here using CMakes CMAKE_INTERPROCEDURAL_OPTIMIZATION, which is -flto=thin for LLVM/Clang). I think this is worth having generally (we do use LTO in some other places, like oss-fuzz). If runtime is too much of an issue, then it could also be dropped. (Chimera itself is also compiled with LTO).

QT in depends doesn’t build (#32744), so is excluded for now.

Chimera has pointed out at least a few quirks, i.e #34390, #34408 and #29963 (review).

DrahtBot commented at 4:42 pm on January 27, 2026: contributor

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/34421.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	maflcko, hebasto

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#34491 (ci: add FreeBSD Clang cross job by fanquake)
#31425 (RFC: Riscv bare metal CI job by sedited)

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.

hebasto commented at 4:43 pm on January 27, 2026: member

Concept ACK.

fanquake force-pushed on Jan 27, 2026

DrahtBot added the label CI failed on Jan 27, 2026

DrahtBot commented at 4:49 pm on January 27, 2026: contributor

🚧 At least one of the CI tasks failed. Task lint: https://github.com/bitcoin/bitcoin/actions/runs/21405805072/job/61629249991 LLM reason (✨ experimental): Lint test failed due to a file permission issue: ci/test/00_setup_env_native_chimera_lto.sh is not executable.

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.

fanquake force-pushed on Jan 27, 2026

maflcko commented at 5:32 pm on January 27, 2026: member

Also seen failures with wallet_backwards_compatibility.py.

I guess this is just due to GNU tar, if no GNU exists? Ref #34390#pullrequestreview-3697587900?

fanquake force-pushed on Jan 27, 2026

fo22Alfaro commented at 7:35 pm on January 27, 2026: none

YA ESTAN SIENDO UBICADOS POR ACCIONES ILEGALES DE MANIPULACIÓN EN MEMPOOL

DrahtBot removed the label CI failed on Jan 27, 2026

in ci/test/00_setup_env_native_chimera_lto.sh:13 in bb6e7d9d2f outdated

 5+# file COPYING or https://opensource.org/license/mit.
 6+
 7+export LC_ALL=C.UTF-8
 8+
 9+export CONTAINER_NAME=ci_native_chimera_musl
10+export CI_IMAGE_NAME_TAG="mirror.gcr.io/chimeralinux/chimera"

maflcko commented at 9:03 am on January 28, 2026:

it is a rolling release, which makes it less reproducible. Any commit that passes CI at one point may fail to pass in the at another point in time (and vice-versa).

Maybe it is annoying, but fine if older commits where the CI passed once no longer passes. Though, i worry about cases where a pull request fails to compile on one day, but not on the next day (or when it is merged). It is a bit like a constant rolling silent merge conflict, because the whole deps tree here is constantly rolling.

I think this task config is useful. However, the ideal place for nightly/rolling CI (like the nightly GCC or nightly clang CI) may not be in the main repo.

The easiest approach could be to run it along the other nightly CI. An alternative could be to split up another monotree repo for nightly CI.

fanquake commented at 3:27 pm on January 28, 2026:

Yea that could be a drawback, however I think the same is already true for existing jobs in the CI. Any macOS job using brew to install dependencies is also rolling, given we don’t pin anything, and just as likely to fail one day to the next. This would have happened, for example, if Qt 6.10 had started shipping before #33571/https://github.com/bitcoin-core/gui/pull/899 had landed, given we just install qt@6.

Maybe an entire rolling distro is too much, but if we are expecting reproducibility in jobs, then we should likely be pinning much more.

maflcko commented at 4:05 pm on January 28, 2026:

Yeah, I really hate the macOS brew CI (and I guess Windows is no different?). However, there is probably a good chunk of devs/users on macOS/Windows, so it may be a net benefit to have those brittle configs.

Chimera Linux seems a bit niche and my preference would be to have at least all Linux tasks be somewhat deterministic (at least the ones running on all pull requests/merges).

fanquake commented at 5:23 pm on January 29, 2026:

Chimera Linux seems a bit niche

Sure, I’m not attached to any particular distro here, just want to add coverage for things that are currently missing (will try achieve the same with something else). Currently I’m less enthused by pushing more things into nightly repos, because that seems to lead to this cycle: #33438 (comment). I think we still have scope to expand the number of jobs in the CI here.

maflcko commented at 5:41 pm on January 29, 2026:

Yeah, coverage for one *BSD would be great. I can’t answer the third-party questsion, so i may not ACK it, but I won’t block it and it seems fine to do.

coverage for musl+llvm may be possible with Alpine as well. I guess you’ll get the same qt compile error there? Though that isn’t going to find the gnu-getopt and gnu-tar issues?

fanquake force-pushed on Jan 28, 2026

DrahtBot added the label CI failed on Jan 28, 2026

in ci/test/01_base_install.sh:35 in 54d88fd262

31@@ -32,7 +32,7 @@ if [ -n "${APT_LLVM_V}" ]; then
32   )
33 fi
34 
35-if [[ $CI_IMAGE_NAME_TAG == *alpine* ]]; then
36+if [[ $CI_IMAGE_NAME_TAG == *alpine* || $CI_IMAGE_NAME_TAG == *chimera* ]]; then

fanquake commented at 3:01 pm on January 28, 2026:

Wonder if we can generalise this to just check for apk, so that it’s not necessary to list image names here?

maflcko commented at 3:12 pm on January 28, 2026:

Yeah, that should work

DrahtBot removed the label CI failed on Jan 28, 2026

hebasto commented at 9:22 pm on January 28, 2026: member

I think this task config is useful. However, the ideal place for nightly/rolling CI (like the nightly GCC or nightly clang CI) may not be in the main repo.

FWIW, a workflow based on this branch has been added to https://github.com/hebasto/bitcoin-core-nightly.

fanquake force-pushed on Jan 29, 2026

DrahtBot added the label CI failed on Jan 29, 2026

DrahtBot commented at 7:06 pm on January 29, 2026: contributor

🚧 At least one of the CI tasks failed. Task Alpine (musl): https://github.com/bitcoin/bitcoin/actions/runs/21487627329/job/61903273252 LLM reason (✨ experimental): Compilation failure due to trailing whitespace being treated as an error (-Werror) in secp256k1.h during building key.cpp.

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.

fanquake force-pushed on Feb 5, 2026

DrahtBot removed the label CI failed on Feb 5, 2026

fanquake force-pushed on Feb 6, 2026

fanquake commented at 10:29 am on February 6, 2026: member

Any opinions on adding the CI config, but not adding it to the runner?

maflcko commented at 11:21 am on February 6, 2026: member

Sure, seems fine. Would be good to include a warning that it is experimental and non-reproducible (rolling release)

hebasto commented at 11:24 am on February 6, 2026: member

Any opinions on adding the CI config, but not adding it to the runner?

Having the CI config is nice. It’ll allow to run CI locally or nightly on the default branch.

ci: add chimera Linux LTO CI job d79249d279

fanquake force-pushed on Feb 6, 2026

fanquake renamed this:
~~[RFC] ci: add Chimera Linux LTO job~~
ci: add Chimera Linux LTO config
on Feb 6, 2026

fanquake marked this as ready for review on Feb 6, 2026

DrahtBot added the label Tests on Feb 6, 2026

fanquake commented at 1:30 pm on February 6, 2026: member

Added an experimental / rolling notice, updated PR description to add another instance where Chimera usage caught something during review (https://github.com/bitcoin/bitcoin/pull/29963#discussion_r2707922298).

maflcko commented at 1:42 pm on February 6, 2026: member

lgtm ACK d79249d2799e7f450d5708ca3366461f5f2069bc

This is adding a config. However, I have not tried running it, nor confirmed that it finds the issues it claims to have found

DrahtBot requested review from hebasto on Feb 6, 2026

hebasto commented at 2:09 pm on February 6, 2026: member

ACK d79249d2799e7f450d5708ca3366461f5f2069bc.

hebasto approved

hebasto merged this on Feb 6, 2026

hebasto closed this on Feb 6, 2026

fanquake deleted the branch on Feb 6, 2026

ci: add Chimera Linux LTO config #34421

Code Coverage & Benchmarks

Reviews

Conflicts