Re:The Pain That Is GitHub Actions
by imp0cat on Thursday March 20, 2025 @04:17AM
(#43420783)
This. Your own runners can cache everything (docker caches, apt caches, ccache outputs...) and can also share the compilation load (icecc for c++). All that gives 5x-10x speed boost.
[ Parent
| on HN ]
Re:The Pain That Is GitHub Actions
by madeofpalk on Thursday March 20, 2025 @05:23AM
(#43421146)
This is true because your CI steps will be running on a lower number of physical machines, ensuring higher cache hits?
Re:The Pain That Is GitHub Actions
by saidinesh5 on Thursday March 20, 2025 @05:33AM
(#43421189)
Kind of - you can also pin runners.("This workflow runs on this runner always"). And caching just means not deleting the artifacts from the file system from the previous runs.
Imagine building Android - even "cloning the sources" is 200GB of data transfer, build times are in hours. Not having to delete the previous sources and doing an incremental build saves a lot of everything.
Gitlab also has some tips here: https://docs.gitlab.com/ci/caching/ on using shared caches, which can help in some scenarios, especially runners in Kubernetes that are ephemeral, ie. created just before a job starts and destroyed afterward.
tldr; "A cache is one or more files a job downloads and saves. Subsequent jobs that use the same cache don’t have to download the files again, so they execute more quickly."
It will probably still be slower than a dedicated runner, but possibly require less maintenance ("pet" runner vs "cattle" runner).