ci: latest cmake in macos?

fanquake commented at 6:07 am on March 19, 2026: member

Should fail re #33144.

ci: latest cmake in macos? 99131b8ac0

DrahtBot added the label Tests on Mar 19, 2026

DrahtBot commented at 6:07 am on March 19, 2026: contributor

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

Reviews

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

fanquake commented at 6:14 am on March 19, 2026: member

Failed (https://github.com/bitcoin/bitcoin/actions/runs/23282218050/job/67697930446?pr=34853#step:9:862):

 0 CMake Error (dev) at src/wallet/CMakeLists.txt:37 (target_link_libraries):
 1  The library that is being linked to, SQLite::SQLite3, is marked as being
 2  deprecated by the owner.  The message provided by the developer is:
 3
 4  The target name SQLite::SQLite3 is deprecated.  Please use SQLite3::SQLite3
 5  instead.
 6
 7This error is for project developers. Use -Wno-error=dev to suppress it.
 8
 9-- Generating done (0.8s)
10CMake Generate step failed.  Build files cannot be regenerated correctly.
11+ cd /Users/runner/work/bitcoin/bitcoin/repo_archive/ci/scratch/build-aarch64-apple-darwin24.6.0
12++ cmake -P /Users/runner/work/bitcoin/bitcoin/repo_archive/ci/test/GetCMakeLogFiles.cmake
13+ cat CMakeFiles/CMakeConfigureLog.yaml

DrahtBot added the label CI failed on Mar 19, 2026

fanquake commented at 6:18 am on March 19, 2026: member

Given that there only seems to be ~5 seconds difference between the currently used brew install step, and the changes here brew update + brew install (along with dropping the workaround + dropping the no outdated dependants check), maybe we should drop those (and explicitly install cmake), so that the macOS jobs are closer to front-running issues with dependencies or build tools, rather than the issues appearing whenever GH happens to update an image?

maflcko commented at 7:23 am on March 19, 2026: member

front-running issues with dependencies or build tools

I think this is a useful goal. However, I am not sure if the CI in this repo is the right place to discover nightly issues. This will just lead to even more intermittent and unrelated CI issues on all ~300/400 pull requests. Keep in mind that the current stream of CI issues is eating already more time than it should as-is, so adding even more to it doesn’t seem helpful.

I think nightly issues should be found with a dedicated nightly canary.

I think there are two options:

Add this to one of the existing nightly CI repos (hebasto/maflcko/willcl-ark/…), or start your own, with the expectation that the person running it is responsible for reporting any relevant issues to the main repo.
Have a dedicated nightly CI workflow in this repo, or in another bitcoin-core repo, with the expectation that the maintainers subscribe to the CI notifications and are responsible to report any relevant issues as a pull request or tracking issue.

My preference would be to go with the first option, or at least have a separate repo for this, because this allows to be move flexible in using any scripts in CI that are maintained by random (possibly compromised) third parties, e.g the *BSD vm scripts. Also, using another repo reduces the load on reviewers to deal with what is basically not Bitcoin-related sysadmin tasks.

fanquake commented at 7:43 am on March 19, 2026: member

However, I am not sure if the CI in this repo is the right place to discover nightly issues. This will just lead to even more intermittent and unrelated CI issues on all

Yea, it already is the case that we have (non-real) intermmitent issues here (random failures, but which don’t seem to catch useful issues), unless we decide to pins things in the macOS and Windows jobs. We are already at the whim of brew / vcpkg / GH etc, and whenever they happen to update dependencies / CI images etc. We also see fairly constant failures in Windows Ci jobs, when, for example, a sub dependency of a dependency of Qt, happens to fail to download, or similar. So, I could agree with more nightly repos, if this repo is made more stable, otherwise we just get more repos, and more things to monitor, that might find more issues, while retaining the existing flakiness here.

maflcko commented at 8:00 am on March 19, 2026: member

So, I could agree with more nightly repos, if this repo is made more stable, otherwise we just get more repos, and more things to monitor, that might find more issues, while retaining the existing flakiness here.

You are right that the current situation is not ideal. However, I don’t think the existing flakiness will be retained. I think at least with macOS, a nightly canary will work fine, because it is “semi-stable”, only changing when GitHub decides to change the image, which happens every few months/weeks, so there is plenty time for us to catch those issues in those weeks.

I think spending time on a nightly canary is useful.

With the changes in this pull request, the idea of dealing with nightly issues on a separate process with a minimally reduced schedule is given up on. I think it is fine to give up, if there was any evidence that a separate repo does not work.

However, there is evidence, that it does work. For example,

Nightly GCC issues are worked around in a Bitcoin Core release branch, even before the GCC release is out: #34471
Same for nightly Clang issues: #31691
…

I don’t see why the same approach would not be possible for cmake nightly issues?

About the Windows download issues: I think this is about intermittent network errors. Generally, in CI, those should be retried. There is a bash retry script, but I think Bash does not work on Windows out of the box. In any case, I think this may be best to track and fix in a separate issue.

maflcko commented at 8:16 am on March 19, 2026: member

About the Windows download issues: I think this is about intermittent network errors. Generally, in CI, those should be retried. There is a bash retry script, but I think Bash does not work on Windows out of the box. In any case, I think this may be best to track and fix in a separate issue.

Nvm, I recall I’ve already re-written this to Python, so this should be trivial to fix. Do you have an example CI failure handy as reference?

edit: fixed in https://github.com/bitcoin/bitcoin/pull/34859

fanquake commented at 9:19 am on March 19, 2026: member

only changing when GitHub decides to change the image, which happens every few months/weeks,

This is only true for things we don’t explictly install (currently includes Cmake). Packages like Qt, which we do explictly install, are not stable, and the most-recent version will always be installed (in our CI here); so we have to frontrun breakage i.e #33571.

if there was any evidence that a separate repo does not work.

We are seeing some evidence that nightly repos are not 100% effective, resulting in churn / time-wasting / confusion from contributors about what is actively supported or needs to be tested when making changes. i.e #33438. There have also been a few instances in our own tracker, where the issues reported seemed to be issues with the nightly repos themselves.

We’ve also seen issues posted after-the-fact (where nobody may be watching/subscribed), i.e #34418 (comment). In this case, on the nightly side, the workaround was retained (for the broken arm64 case), so it’s not clear if things are being ignored, or tracked/followed up on, or just remain broken (I don’t see a tracking issue in https://github.com/hebasto/bitcoin-core-nightly/issues or our repo. Seems relevant given #31388).

fanquake commented at 9:20 am on March 19, 2026: member

(Will close this for now in any case, as any potential breakage will be fixed shortly with the backports)

fanquake closed this on Mar 19, 2026

fanquake deleted the branch on Mar 19, 2026

maflcko commented at 11:52 am on March 19, 2026: member

only changing when GitHub decides to change the image, which happens every few months/weeks,

This is only true for things we don’t explictly install (currently includes Cmake). Packages like Qt, which we do explictly install, are not stable, and the most-recent version will always be installed (in our CI here); so we have to frontrun breakage i.e #33571.

Ok, I see. This makes it indeed worse.

I think we agree that frontrunning is useful here, and I think it should still be possible, because there will be a time between the package manager (brew) picking the latest version and that version having been released.

Not sure how easy it would be to implement that in a different repo.

Though, I think this pull doesn’t improve the situation, because:

before this pull, if a breaking change hits a dependency and then the package manager, CI will fail on all pull requests.
after this pull, the same happens, possibly earlier.

At least for this specific cmake sqlite3 thing, making it fail later did also work, and I think is preferable.

We are seeing some evidence that nightly repos are not 100% effective, resulting in churn / time-wasting / confusion from contributors about what is actively supported or needs to be tested when making changes. i.e #33438.

Right, I see, and I agree it is not ideal.

There have also been a few instances in our own tracker, where the issues reported seemed to be issues with the nightly repos themselves.

Right, so this would be an argument against adding a let’s say *BSD VM task in this repo, if the outcome is that unrelated OOM issues in the VM itself lead to issues here.

We’ve also seen issues posted after-the-fact (where nobody may be watching/subscribed), i.e #34418 (comment). In this case, on the nightly side, the workaround was retained (for the broken arm64 case), so it’s not clear if things are being ignored, or tracked/followed up on, or just remain broken (I don’t see a tracking issue in https://github.com/hebasto/bitcoin-core-nightly/issues or our repo. Seems relevant given #31388).

Good point. I think in this case, it should be trivial to add another Windows cross-test CI task inside this repo. There should be no concerns around non-reproducibility, or intermittent issues, or otherwise any other concerns, right?

edit: Ok, I see in this particular case it is unclear if the issue is not with the target stdlib itself. In that case, it would raise concerns to offer release binaries for this target. So I think the current status is that this target is currently unsupported and remains so. If the target is supported (and possibly shipped), then it should be trivial (and useful) to add CI support for the target as well.

hebasto commented at 3:38 pm on March 19, 2026: member

We’ve also seen issues posted after-the-fact (where nobody may be watching/subscribed), i.e #34418 (comment). In this case, on the nightly side, the workaround was retained (for the broken arm64 case), so it’s not clear if things are being ignored, or tracked/followed up on, or just remain broken (I don’t see a tracking issue in https://github.com/hebasto/bitcoin-core-nightly/issues or our repo. Seems relevant given #31388).

I appreciate the reminder. I’ve opened a tracking issue here: https://github.com/hebasto/bitcoin-core-nightly/issues/213.

hebasto commented at 9:41 pm on March 22, 2026: member

FWIW, added https://github.com/hebasto/bitcoin-core-nightly/pull/217.

ci: latest cmake in macos? #34853

Reviews