| I'm currently migrating some stuff from azdo to GHA, and have been putting past lessons to serious use: * Perf: don't use "install X" (Node, .Net, Ruby, Python, etc.) tasks. Create a container image with all your deps and use that instead. * Perf: related to the last, keep multiple utility container images around of varying degrees of complexity. For example, in our case, I decided on PowerShell because we have some devs with Windows and it's the easiest to get working across Linux+Windows - so my simplest container has pwsh and some really basic tools (git, curl, etc.). I build another container on that which has .Net deps. Then each .Net repo uses that to: * Perf: don't use the cache action at all. Run a job nightly that pulls down your code into a container, restore/install to warm the cache, then delete the code. `RUN --mount` is a good way to avoid creating a layer with your code in it. * Maintainability: don't write big scripts in your workflow file. Create scripts as files that can also be executed on your local machine. Keep the "glue code" between GHA and your script in the workflow file. I slightly lie here, I do source in a single utility script that reads in GHA envars and has functions to set CI variables and so forth (that does sensible things when run locally). Our CI builds are stupid fast. Comparatively speaking. For the OP (I just sent your pricing page to my manager ;) ): having a colocated container registry for these types of things would be super useful. I would say you don't need to expose it to the internet, but sometimes you do need to be able to `podman run` into an image for debug purposes. [1]: https://docs.github.com/en/actions/how-tos/writing-workflows... |
It essentially makes a copy of your entire state of the runner, which you can then use in subsequent runs, with no concurrency limits.
This essentially automates out a lot of the work you're doing to make the jobs faster.
https://docs.warpbuild.com/snapshot-runners
We provide a product similar to Blacksmith.