Fixes #33293
Clear out space on jobs running on GHA by deleteing unnecessary files.
Raised in #33293 which pointed to a solution like https://github.com/google/oss-fuzz/commit/b7f04d782277638a67bc44865de445977eed4708 which is adapted slightly here.
Only runs when cache provider (runner) is gha.
A run on my fork can be seen here: https://github.com/willcl-ark/bitcoin/actions/runs/19703413734/job/56444984809
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33514.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | maflcko, janb84, m3dwards |
| Concept ACK | hebasto |
| Stale ACK | pablomartin4btc, hodlinator |
If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.
No conflicts as of last run.
Maintaining an action in this repo which only caters to forks is not ideal, but unless GH increases the space on runners, or provides a “slim” image variant, then it might be the best there is for now.
As it doesn’t run in this repo it should at least never break our CI.
Which one is the chain needing this change?
Ah I was slightly unclear; this actually applies to “personal forks” (e.g. my own, your own) as well as actual coin-forks. Anywhere where Cirrus runners, which have more space, are not being used.
So how does this relate to #33480 (remove centos for alpine) . Is this a fix until that PR gets merged ?
I had thought the alpine job would use less space, but I think they are ~ equivalent, so this fix is still needed on that job for runs on forks (see above) to not run out of space.
ACK 014b9f6268390b78e66e1be24813d3f069588442
PR introduces new CI action. This action will remove unnecessary packages to reduce space. This action will only run on GHA runners and will save about 22gb.
Kinda surprised about the space savings or why are the packages are there in the first place. Anyhow this will help to resolve the GHA space problems for Centos job. (resolves #33293)
EDIT: It’s now more clear that the files are removed of the GHA runner image/host.
516@@ -516,6 +517,10 @@ jobs:
517 with:
518 cache-provider: ${{ matrix.provider || needs.runners.outputs.provider }}
519
520+ - name: Clear unnecessary files
521+ if: ${{ matrix.freeup-space == true }}
0 if: ${{ needs.runners.outputs.provider == 'gha' }}
nit: Could run it for all tasks, to avoid having to select them individually?
Don’t see a problem with the current approach. Would just prefer:
0 if: ${{ matrix.freeup-space }}
Don’t see a problem with the current approach.
The problem is that GHA does not run in this repo, so there likely won’t be any indication when this setting is needed. It can practically most likely only be removed/added in a follow-up, which increases the churn a bit.
If the overhead is too large, the step could be run in the background, albeit that would be dropping the reporting feature.
No strong opinion, though, just wanted to mention it.
Yeah it’s a fair shout.
The step in my run in OP took 4 mins, but I have seen it also take 2 minutes. Either way that’s “wasted time” on the run, although this doesn’t particularly matter on a fork run IMO, as they’re way less time-sensitive, less likely to be queued up with a backlog (and using free compute).
When each job is takining in the order of 1-2 hours, adding 4 minutes on doesnt’ feel that problematic to me.
nit: Could run it for all tasks, to avoid having to select them individually?
OK I took this suggestion in c01214e72b9876c59924c98e96f43906f5df3353 as the future-proofing/churn-reduction seems worth it.
0Space freed: 22GB (23654664KB)
https://github.com/pablomartin4btc/bitcoin/actions/runs/18266112018/job/52000630402
It happened to me a couple of days ago: https://github.com/pablomartin4btc/bitcoin/actions/runs/18234273673/job/51924700571
481@@ -482,6 +482,7 @@ jobs:
482 fallback-runner: 'ubuntu-24.04'
483 timeout-minutes: 120
484 file-env: './ci/test/00_setup_env_native_centos.sh'
485+ freeup-space: ${{ needs.runners.outputs.provider == 'gha' && true || false }} # Only needed on hosted GH runners (forks)
nit: Remove leftovers, unless they serve a purpose?
0 freeup-space: ${{ needs.runners.outputs.provider == 'gha' }} # Only needed on hosted GH runners (forks)
ACK 014b9f6268390b78e66e1be24813d3f069588442
Was curious if it would take less time to switch to the stream10-minimal container, but it seems to come with the same amount of /usr/local/lib/android files, taking over 3min to remove regardless (https://github.com/hodlinator/bitcoin/actions/runs/18273895919/job/52021497688#step:6:249).
Edit: Just realized the /usr/local/lib/android being removed exists on the host Ubuntu OS, not inside the CentOS container.
Was curious if it would take less time to switch to the stream10-minimal container,
Just for reference, the added step here runs before any of the CI logic is run, so changing the CI config should not have any effect on this step here.
Was curious if it would take less time to switch to the stream10-minimal container,
Just for reference, the added step here runs before any of the CI logic is run, so changing the CI config should not have any effect on this step here.
Yeah, just realized /usr/local/lib/android was being removed on the host OS, not inside the container.
re ACK c01214e72b9876c59924c98e96f43906f5df3353
Changes sinds last ACK:
I like the solution because the alternative would be to create an custom GHA Image (as suggested by gh) which would be a more maintenance burden than this script.
A run applying to all jobs when using GHA can be seen here: https://github.com/willcl-ark/bitcoin/actions/runs/18274913987
Looking there, it seems like the cleanup step can take up to 10 minutes to complete i.e. https://github.com/willcl-ark/bitcoin/actions/runs/18274913987/job/52024710440. Although I guess that is less of an issue if it’s not running in this repo.
A run applying to all jobs when using GHA can be seen here: willcl-ark/bitcoin/actions/runs/18274913987
Looking there, it seems like the cleanup step can take up to 10 minutes to complete i.e. willcl-ark/bitcoin/actions/runs/18274913987/job/52024710440. Although I guess that is less of an issue if it’s not running in this repo.
This is even longer than I’ve seen it take previously. Happy to revert this to only apply to the CentOS job if preferred. Seems pointless to add 10 mins runtime onto like 11 jobs where it’s not needed…
re-ACK c01214e72b9876c59924c98e96f43906f5df3353
I’m okay with applying broadly to ease maintenance, with a very slight preference for changing it back to more surgically apply to CentOS.
A run applying to all jobs when using GHA can be seen here: https://github.com/willcl-ark/bitcoin/actions/runs/18274913987
Looking there, it seems like the cleanup step can take up to 10 minutes to complete i.e. https://github.com/willcl-ark/bitcoin/actions/runs/18274913987/job/52024710440. Although I guess that is less of an issue if it’s not running in this repo.
Ok I missed this in my review, I also have a slight preference to revert this to only apply to the CentOS job. I would say lets revert and if the cleanup action needs to be applied on more actions in the future, then go for the generic solution (as applied now) to reduce churn.
I wondered if it could be sped up and it looks like deleting /usr/local/lib/android is what takes the time. It’s 9.8gb so probably not worth skipping the deletion. I tried a few tricks like rsyncing an empty directory over it but it looks like rm -rf is king in terms of speed.
So I concur, perhaps best to just apply to the job that needs it.
515@@ -516,6 +516,10 @@ jobs:
516 with:
517 cache-provider: ${{ matrix.provider || needs.runners.outputs.provider }}
518
519+ - name: Clear unnecessary files
520+ if: ${{ needs.runners.outputs.provider == 'gha' }}
Yes, this is set by the determine-runners job: https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/.github/workflows/ci.yml#L33-L46
If you have cirrus runners in your own repo you can set a repo variable REPO_USE_CIRRUS_RUNNERS to your repo name to enable cirrus runners in your fork.
You will see the setting in the Annotations section of the Actions tab on a run:
Happy to revert this to only apply to the CentOS job if preferred. Seems pointless to add 10 mins runtime onto like 11 jobs where it’s not needed…
While testing on with sv2-tp https://github.com/Sjors/sv2-tp/pull/37 I also noticed the cleanup task is quite slow. Because my codebase is much smallers, it basically doubles the runtime. Of course I could simply not cherry-pick this commit - I haven’t run out of space yet - but just FYI.
re ACK 014b9f6268390b78e66e1be24813d3f069588442
changes since last ack:
Clear unnecessary files action on the 'CentOS, depends, gui'
Can this be closed, or is there something left to be done here?
Looks like a lot of hassle/bike-shedding for something that hasn’t happened for about a month now.
Hitting this again on my and @TheCharlatan’s fork: m3dwards/bitcoin/actions/runs/19539048875/job/55940226257
Re-opening based on above report, can close again if someone else has another approach they would prefer.
6+ - name: Clear unnecessary files
7+ shell: bash
8+ env:
9+ DEBIAN_FRONTEND: noninteractive
10+ run: |
11+ set +e
0 set +o errexit
nit: Would be nice to use the long names, so that the code can be understood without looking up the long name in the manual.
18+ BEFORE_AVAIL=$(df / | awk 'NR==2 {print $4}')
19+
20+ echo "Cleaning up unnecessary packages..."
21+ time sudo apt-get remove --purge -y firefox google-chrome-stable powershell
22+ time sudo apt-get autoremove -y
23+ time sudo apt-get clean
40+ done
41+
42+ echo "Disabling swap"
43+ sudo swapoff -a
44+ sudo rm -f /swapfile
45+
left some nits.
I guess I don’t understand why this one takes 5 minutes, but basically the same takes 1 minute in https://github.com/hebasto/bitcoin-core-nightly/actions/runs/19678632177/job/56366955874?pr=91#step:3:1.
I don’t have a strong opinion, but I still think this is better run on all tasks, and constantly maintaining which task needs it (or can it have removed) does not seem like a good use of time?
If the duration is a concern, all of this could be replaced with a one-line background task: sudo bash -c '(ionice -c 3 nice -n 19 rm -rf /usr/share/dotnet/ /usr/local/graalvm/ /usr/local/.ghcup/ /usr/local/share/powershell /usr/local/share/chromium /usr/local/lib/android /usr/local/lib/node_modules)&'
Please rebase.
Clear out space on the centos job be deleteing unnecessary files.
Raised by #33293 which pointed to a solution like https://github.com/google/oss-fuzz/commit/b7f04d782277638a67bc44865de445977eed4708
Only runs when cache provider (runner) is `gha`, and on the CentOS job.
Please rebase.
Sorry, was waiting to see if @maflcko ’s background task approach works before adopting it here. I tested it in my fork here where it appears to have worked successfully.
So I have pushed e07e57368e9fab8ecfc140d44aef7db9b23c7ce0 here which:
gha runners`)
lgtm ACK e07e57368e9fab8ecfc140d44aef7db9b23c7ce0
Missing ci: prefix in the title?
ACK e07e57368e9fab8ecfc140d44aef7db9b23c7ce0
Clever to run the removal in the background ! I was wondering where the output goes but that goes no-where (A thing to keep in mind for the future when we are debugging this)
We could even go a bit more aggressive (if needed) and delete /usr/local/.ghcup(6gb) and others
ACK e07e57368e9fab8ecfc140d44aef7db9b23c7ce0
Like that it runs in the background, dislike that it hides any errors. It’s simple enough that I don’t think it’s worth being more complex to catch any problems.
As an experiment I removed CMakeFiles directories after cmake ran which deletes a few GBs in under a second which was just enough to get my fork building again. I prefer the solution in this PR however.
Relevant log output (full log):
0Tue, 25 Nov 2025 21:15:42 GMT
17.6G /home/runner/work/_temp/build
2Tue, 25 Nov 2025 21:15:42 GMT
3+ find /home/runner/work/_temp/build -type d -name CMakeFiles -exec rm -rf '{}' +
4Tue, 25 Nov 2025 21:15:42 GMT
5+ du -sh /home/runner/work/_temp/build
6Tue, 25 Nov 2025 21:15:42 GMT
74.7G /home/runner/work/_temp/build