Cache: GHES support

[wichert]

According to the GH Actions Guide caching is supported on GitHub Enterprise Server. However the code bails if GHES is detected.

Is GHES support in the pipeline, or should the documentation be updated to reflect that this is not supported?

[dhadka]

@wichert The cache action will not be supported on GitHub Enterprise Server, at least for the initial release. If there's a strong demand for caching on GHES, this could definitely change. Part of the reasoning behind this decision is:

1. Since GHES uses self-hosted runners, dependencies are typically cached on the runner by whatever dependency management tool is being used (npm, maven, etc.), so saving these to an external cache would be less efficient.

2. Some workflows use the cache to share data between multiple jobs in a workflow. GHES will have the upload and download artifact actions available.

The part of the docs I believe you're referring to, which says "GitHub Actions is available with GitHub Free, GitHub Pro, GitHub Free for organizations, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server, and GitHub One.", is talking about GitHub Actions as a whole and not the caching action, but we can definitely update that statement to make it clearer.

[dhadka]

I've filed an issue with our docs team to consider clarifying that text.

[wichert]

@dhaka Using caches on self-hosted runner directly doesn't work if you use containers, which I would expect to be pretty common. No doubt you'll have better usage numbers though :). In our case we need to emulate various environments, so we need to use containers.

How are you measuring strong demand? Would it help if I ask our IT department to submit a request via a sales contact?

[dhadka]

Adding @ahdbilal, the product manager for Actions, for awareness of this issue and input on how customers should provide feedback.

[ahdbilal]

@wichert Thanks for the feedback! I have recorded your input and I will escalate it internally. Can you share more details on how you are using containers on self-hosted runners? Will love to get on a call with you to go into details. Let me know if you are up for that!

[wichert]

@ahdbilal I'm happy to get on a call. Can you email me directly so set can figure out a time and exchange contact information?

[dicko2]

@ahdbilal We also have been looking forward to the caching feature onprem, happy to chat about it too if you need more input

@dhadka Onprem package management solutions dont cut the mustered and I'll give some common use cases

Yarn install and node-modules
Scala and SBT

Our yarn install steps take 4-5minutes on average, even using the local npm servers, because it builds a dependency tree and this takes most of the work.

SBT, is even worse, initial installs take up to an hour (or even more in some case) for projects, again the times is not from downloading, its analysis of dependency tree, and yes this is even when using coursier

Now a layman might argue that our onprem runners persist and we have things cached for long periods, but we follow principles of immutable infrastructure and don't let any of our runners live for longer than 12-24 hours to reduce on maintenance.

We've hacked together some custom caching solution that we use for these things, and was looking into doing something a little more concert for ourselves until we saw this feature coming we though it would save us a lot of work.

So it would be nice if the CI platform takes care of this for us. Like gitlab ci does for example https://docs.gitlab.com/ee/ci/caching/

[dicko2]

This is the pain we have :)

[yogurtearl]

Sharing dep cache across repos can lead to perf issues.

Also, it is not just about caching downloaded deps, but also about caching computed outputs.

E.g. grade build cache. You don't want to share that across repos.
https://docs.gradle.org/current/userguide/build_cache.html

[kevincobain2000]

Hi,

I understand why caching is not supported for self-hosted runners on GHES. Although, this is a major setback if we consider moving from other CI solutions. Caching especially for node_modules is rather important.

I hope you support it soon in the future. As for now, I do our custom caching over HTTP. So instead of mounting volumes, we POST the tar of the dependency folder to the webserver and the same way GET at the time of installation. At least this is working ok for now.

https://github.com/kevincobain2000/action-cache-http

There is the overhead of HTTP of course, however, it is still better than having to do npm/yarn install on each build. I have added screenshots for the comparison on a few samples with or without cache here (medium article).

[tetchel]

hi all, between https://github.com/actions/cache and https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows it would be nice if there were a clear source of truth that says "The actions cache is not supported on GHE server" other than this issue.

I agree with the original commenter that the generic "Actions is supported on [...]" header at the top of the caching page adds to the confusion here.