As cirrus is closing down, switch to warpbuild runners.
Switch runner and provider names over. We now use GHA cache, so we don't need to switch that over here.
As cirrus is closing down, switch to warpbuild runners.
Switch runner and provider names over. We now use GHA cache, so we don't need to switch that over here.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35378.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please copy-paste <code><!--meta-tag:bot-skip--></code> into the comment that the bot should ignore.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
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-->
18 | @@ -19,7 +19,7 @@ concurrency: 19 | 20 | env: 21 | CI_FAILFAST_TEST_LEAVE_DANGLING: 1 # GHA does not care about dangling processes and setting this variable avoids killing the CI script itself on error 22 | - REPO_USE_CIRRUS_RUNNERS: 'bitcoin/bitcoin' # Use cirrus runners for this repo, instead of falling back to the slow GHA runners 23 | + REPO_USE_WARP_RUNNERS: 'bitcoin/bitcoin' # Use warp runners for this repo
Why remove the second part of the sentence?
Just while I was touching that line didn't really feel it was necessary. Happy to add it back though if you prefer :)
I guess it is a bit obvious, but this is the only reason all this dancing is required here. If there was an easy way to use faster/larger GH runners, we'd just do that :sweat_smile:
So my preference would be to keep it, but not a blocker.
Also, the pull description could be updated to remove "Draft ..."?
done both
Concept ACK
One other pertinent detail that's probably worth mentioning here, is that Warp charges per minute used, vs Cirrus which was "$x per vCPU per month".
The benefit we will see is that we can start all jobs concurrently, always (I am not aware of any limit on concurrency).
We will want to make even more sure than usual that our CI runs are wall-time efficient though, to minimise costs.
We will want to make even more sure than usual that our CI runs are wall-time efficient though, to minimise costs.
Are there any docs (wrt runner types, etc) or dashboards (wrt usage) on warp?
Also, maybe the commit could be squashed, as they mostly modify the same lines thrice?
We will want to make even more sure than usual that our CI runs are wall-time efficient though, to minimise costs.
Are there any docs (wrt runner types, etc) or dashboards (wrt usage) on warp?
Yes there are some observability dashboards, for example can view resource usage per job:
<img width="2380" height="1417" alt="image" src="https://github.com/user-attachments/assets/c89ba6e5-8faf-4abe-bc79-094f521c393d" />
and docs are available at: https://www.warpbuild.com/docs/ci/cloud-runners
Also, maybe the commit could be squashed, as they mostly modify the same lines thrice?
Agree, the diff has shrunk so much these deserve to be squashed. Done.
Concept ACK.
According to lscpu, they are using the same 7950X3D machines, so nothing should change in that regard.
Looks like you forgot to update the readme?
$ git grep -i cirrus 9053538a45df1fca78fdd79495b99dd95e1cc1a2 ci
9053538a45df1fca78fdd79495b99dd95e1cc1a2:.editorconfig:# .cirrus.yml, etc.
9053538a45df1fca78fdd79495b99dd95e1cc1a2:ci/README.md:1. Register with [Cirrus Runners](https://cirrus-runners.app/) and purchase runners.
9053538a45df1fca78fdd79495b99dd95e1cc1a2:ci/README.md:2. Install the Cirrus Runners GitHub app against the GitHub organization.
9053538a45df1fca78fdd79495b99dd95e1cc1a2:ci/README.md:It is also possible to use your own Cirrus Runners in your own fork with an appropriate patch to the `REPO_USE_CIRRUS_RUNNERS` variable in ../.github/workflows/ci.yml
9053538a45df1fca78fdd79495b99dd95e1cc1a2:ci/README.md:NB that Cirrus Runners only work at an organisation level, therefore in order to use your own Cirrus Runners, *the fork must be within your own organisation*.
468 | timeout-minutes: 120 469 | file-env: './ci/test/00_setup_env_native_asan.sh' 470 | 471 | - name: 'macOS-cross to arm64' 472 | - cirrus-runner: 'ghcr.io/cirruslabs/ubuntu-runner-amd64:24.04-sm' 473 | + warp-runner: 'warp-ubuntu-2404-x64-4x'
Could use ubuntu-latest, to avoid having to touch this ever again?
Why use a Github runner for this job specifically?
Could use
ubuntu-latest, to avoid having to touch this ever again?
For all 2404 jobs or only this one?
I don't mind switching them all to latest, but we'd have to accept there will be a day they all increment to the next released version. Is that what we want?
Could use
ubuntu-latest, to avoid having to touch this ever again?For all
2404jobs or only this one?I don't mind switching them all to
latest, but we'd have to accept there will be a day they all increment to the next released version. Is that what we want?
For all, except for the Asan-usdt one, which requires 24.04.
I think we don't care about the Ubuntu version otherwise, since everything is in docker, so having to bump manually is just busy-work?
Yep sounds good to me. Done in 94ae85405f8b7adb160d2f8de4aa0acee6717152
lgtm
Concept ACK
Concept ACK
I've also run it on my fork: https://github.com/m3dwards/bitcoin/actions/runs/26519588128
Still forgot the readme? #35378 (comment)
Still forgot the readme? (earlier comment)
Readme (fully) updated now.
Alpine job failure looks like flake.
ACK 4bdd46ace37f02da062a53a2943caeddca4ed8f9
Ran on my own fork, witnessed "Runner name: 'warp-8x-x64-whbg8pwh4yea4g8l'" on this PR CI run as well as "Cache restored successfully" so warp machines can pull GHA cache fine. Also double checked the sizes match.
review ACK 4bdd46ace37f02da062a53a2943caeddca4ed8f9 🤾
<details><summary>Show signature</summary>
Signature:
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 4bdd46ace37f02da062a53a2943caeddca4ed8f9 🤾
RSHQjoTjKJbTMqED3HHeLsllpk31D6CukaFihKCIQ8jgxitj8LNLbExX8A6hSLFJSoeejTOjdcv5t4RLkQlsAw==
</details>
453 | timeout-minutes: 120 454 | file-env: './ci/test/00_setup_env_native_iwyu.sh' 455 | 456 | - name: '32 bit ARM' 457 | - cirrus-runner: 'ubuntu-24.04-arm' # Cirrus' Arm runners are Apple (with virtual Linux aarch64), which doesn't support 32-bit mode 458 | + warp-runner: 'ubuntu-24.04-arm' # Warp's Arm runners don't support 32-bit mode currently
Warp's Arm runners don't support 32-bit mode currently
Is this documented somewhere, or has it been confirmed in another way?
ACK 4bdd46ace37f02da062a53a2943caeddca4ed8f9.
In the future, we might want to remove "cirrus" from here:https://github.com/bitcoin/bitcoin/blob/d12d8e52d23f04944f604ca88d645c440e01552b/.editorconfig#L16