-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow passing custom ACTIONS_CACHE_URL
#1695
base: main
Are you sure you want to change the base?
Conversation
@robherley, @bethanyj28 would you mind taking a look at this? |
Any feedback on this PR? Is there something I should implement differently or something missing? I will gladly do anything to get this PR merged. |
Here are some more PRs mentioning the same issue: Would be great to have this feature! I don't see any real problem or security risk with this. Am I missing something? Would there be a safer way to allow for overwriting the cache server url? Please let me know 🙏 @robherley @bethanyj28 |
Would be great to have this option! It is hard to overwrite the cache url in self-hosted runners currently. |
In the meantime we created a simple fork that patches compiled JavaScript in See here how to run it with your own implementation of the Caching API. |
Patching the binary also works, but it’s frustrating not to be able to do it correctly. It's such a small patch.. |
I'm beginning to feel like only Github staff contributions are welcome in this repo 🥲 |
I tried contacting a staff member via email to review this PR. Fingers crossed! 🤞🏻 |
The runner script sets the `ACTIONS_CACHE_URL` using the value from the system connection. Currently, there's no way to override it. Some community users use custom cache solutions with self-hosted runners. The need to maintain a fork of `actions/runner` or `actions/toolkit`, and `actions/cache` to override the value is their solution. However it leads to significant maintenance work. If the runner script allows the `ACTIONS_CACHE_URL` value to be overridden by the `CUSTOM_ACTIONS_CACHE_URL` environment variable, it makes life a lot easier for the community, myself included. An alternative solution could involve allowing the base URL value in `actions/toolkit` to be overridden. Several individuals have submitted similar PRs to this one actions/toolkit#1695, but they have not received adequate attention from the maintainers.
The runner script sets the `ACTIONS_CACHE_URL` using the value from the system connection. Currently, there's no way to override it. Some community users use custom cache solutions with self-hosted runners. They need to maintain a fork of `actions/runner` or `actions/toolkit`, and `actions/cache` to override the value in their solution. However it leads to significant maintenance work. If the runner script allows the `ACTIONS_CACHE_URL` value to be overridden by the `CUSTOM_ACTIONS_CACHE_URL` environment variable, it makes life a lot easier for the community, includes myself. An alternative solution could involve allowing the base URL value in `actions/toolkit` to be overridden. Several individuals have submitted similar PRs to this one actions/toolkit#1695, but they have not received adequate attention from the maintainers.
I've submitted a PR to introduce a similar feature into the runner script. I hope one of them merges. actions/runner#3411 |
Hi @Link- , Enabling the overwriting the |
Closes #1051
Currently it is not possible to overwrite the
ACTIONS_CACHE_URL
which is used for communicating with the cache api. TheACTIONS_CACHE_URL
is always overwritten by the runner itself (runner code snippet).Being able to overwrite this environment variable is crucial for using the
actions/cache
action with self-hosted runners, as it allows for a self-hosted caching solution.To set a custom
ACTIONS_CACHE_URL
, you just need to define theCUSTOM_ACTIONS_CACHE_URL
(open for naming suggestions) env var, which takes precedence over the default cache url env var.Self-hosting an actions cache server is a much requested feature and this PR would make that way easier
Other issues/discussions: