can we cache Docker layer of Super-linter image in Github action

[ABRAJ11]

Thanks for Awesome action . Currently the Docker pull takes around 1-2 min in pulling docker image . can we enable caching of super-linter container image to enable fast execution of workflow

[osfanbuff63]

I don't think that you can right now - but this is a much-needed feature since the docker pull takes 2-3x more (at least) vs the rest of the workflow.

[Shahard2]

Any updates on this one?

[BretFisher]

If we're talking about public runners, I think what you're asking is "can the public runner VMs cache the super-linter images in docker's image cache when they are built?"

In that case, you'd need to request it being added to the image list for Linux VM builds, which currently only caches distro-specific images AFAIK.

[YElyousfi]

What about using actions/cache just to speed things up on a workflow level?

[BretFisher]

Hmm, I doubt that could work in the current model, and also unlikely it would improve speed.

Speed: You're either downloading the image from a registry during the docker step, or downloading the cache during a different step. Also, container registries are optimized for multiple streams (one per layer) so they download faster in tandem. I doubt the cache would do the same for a stored file system.

Compatibility: You would need to reconfigure the Docker Engine (installed already on the public runners) to see a different location (the cache dir) in order to store images there. Docker can't store image layers in a different place at will. This question about actions/cache+docker has been asked and answered multiple times, and the answer is that cache doesn't support docker image cache.

Workaround: There is a solution, though, and it's to setup your own private runners and cache all the images you'd need on those runners during initial setup. I've seen setups that autoscale their own runners (so none are running when you aren't using them) and they seed an image list during setup.

[lkraav]

Is more caching opportunity available with self-hosted runners?

[BretFisher]

Yes, if your self-hosted runner is long-lived, and you don't prune docker's image cache, then the super-linter image would be cached.

Note that most of the self-hosted runner cloud solutions destroy idle runners, causing similar issues to public runners where the docker image cache is blank on each Job.

Also, for long-running self-hosted runners, you'll quickly find that image caching will fill the disk, and will require something like a daily docker image prune -af --filter "until=24h" to remove old images. This would also cause the removal of super-linter, but at least it would only be pulled once a day 😉.

[ferrarimarco]

I think this is more on the GitHub Actions runners side, rather than on super-linter side. I would open an issue in the hosted runners images repo.