Complete non-ephemeral configuration examples?

[donovanmuller]

Assuming I want to run non-ephemeral runners (to speed up builds) and have the following persisted/"cached" between workflows/jobs:

• Local Maven repositories (I.e. ~/.m2/repository)
• Docker layers (I.e. reusing image layers across workflows/jobs)
• Actions tool cache

What are the configurations currently being used to achieve this (assuming this is possible for all of the above)?

I am aware of:

• Stateful Runners
• ephemeral: false on a RunnerDeployment

but looking for any advise/examples of how the storage configuration is setup specifically. Without #612, are the above points possible using RunnerSet? If not, does an NFS mount provide some of the points? Etc.

Thanks in advance...

[toast-gear]

This doesn't answer the question of strategies for non-ephemeral runners however I would ask yourself if you really need them first, consider the below options for performant pipelines using ephemeral runners first:

• https://github.com/actions/cache

This works well in my environment for speeding up builds the limitation here is you only get 5GB of cache storage per repository and that is shared across all branches I believe. The main drawback with this is spikey performance, if you are tracking pipeline speed in your metrics it can skew the data a bit unless you can highlight which fast builds were fast because they hit the cache and which slow builds were slow because they didn't hit the cache.

• an upload / download pattern in your pipelines for dependencies via https://github.com/actions/upload-artifact and https://github.com/actions/download-artifact

This also works well in my environment for speeding up builds. We will upload built dependencies into GitHub's artefact storage (you could do a similar thing with S3 or Artifactory etc though too for example). Then downstream jobs will pull in the dependencies preventing the need for a rebuild. You could certainly design your pipelines around this pattern so they always pull in their dependencies from something storage and have a process for bumping them etc

The nice thing with this approach is consistent performance making pipeline metrics easier. If builds are getting slower it will be because the pipeline is getting slower for whatever reason and probably needs looking at.

• https://github.com/docker/build-push-action/blob/master/docs/advanced/cache.md#github-cache

Use the GitHub repository cache to store docker layers. I've used it in my environment and it works well, especially for larger images.