-
Notifications
You must be signed in to change notification settings - Fork 37.8k
ci: Disable cache save for pull requests in GitHub Actions #28292
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
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concept ACK
key: ${{ github.job }}-ccache-${{ github.run_id }} | ||
restore-keys: ${{ github.job }}-ccache- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does this specify both keys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we are interested in the restore-keys
input only, the key
input is required, thus, it cannot be avoided.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, maybe use the same value for both, or is there a reason to use different values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... is there a reason to use different values?
Yes, it is. github.run_id
is unique for every run. That is why the restore-keys
input contains prefixes that are expected to match. The latest matched cache will be restored.
|
||
- name: Save Ccache cache | ||
uses: actions/cache/save@v3 | ||
if: github.event_name != 'pull_request' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also disable it for branches other than master
, to make sure that storage is constant, even if there was an intermittent push to a backport branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, nvm. Looks like caches are immutable anyway, so this can't be achieved, I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it is still better to only have caches for a single branch, as they can't be re-used for other branches anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the main repository, caches for backport branches will be evicted after 7 days of non-using them.
However, the current logic seems useful for fork repos, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that (assuming a cache size per push of $n
GB, and a total limit of 10GB), 10/n pushes to a backport branch will evict the main cache. For example, for n=5, 2 pushes are enough.
Though, it is only a cache, so I guess it doesn't matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a contributor's topic branch in their personal repo, the workflow will be triggered by a push
event. So the updated push will reuse the cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can anyone with a fork clobber our cache?
No.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can someone elaborate on why branches in forks of this repository are something we need to consider when deciding on our caching stratergy for this repository?
I use CI in my personal repo before pushing my branch into the pull request. And I want to use CI with some efficiency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a contributor's topic branch in their personal repo, the workflow will be triggered by a
push
event. So the updated push will reuse the cache.
No? I think it will use the latest cache, which may be from a different branch, because the cache key isn't included the branch name, so I don't think this will work.
Edit: Maybe it does: https://github.com/actions/cache/blob/main/tips-and-workarounds.md#force-deletion-of-caches-overriding-default-cache-eviction-policy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a contributor's topic branch in their personal repo, the workflow will be triggered by a
push
event. So the updated push will reuse the cache.No? I think it will use the latest cache, which may be from a different branch, because the cache key isn't included the branch name, so I don't think this will work.
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#example-using-multiple-restore-keys: a feature branch is considered before the default branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm ACK
f1bd112
to
d70fabd
Compare
I guess as an alternative, the ghcr can be used to store a ccache? This would require a bit more code on our side, and maybe a few more permissions to be enabled? Though, if the write-permissions are limited to the |
For now, only two jobs, namely native macOS and Windows, are planned to run on GitHub Actions. It should work fine at this scale, no?
I'm not sure about how to make "the write-permissions are limited to the |
Anyway, it won't work with non-Linux runners out-of-the-box. |
Looks like CI is red, but it is not shown here? |
I'm kindly asking you to update Actions permissions according to this PR description. |
Should be available now. |
d70fabd
to
a0f9b09
Compare
Otherwise, multiple pull requests fill GitHub Actions cache quota shortly.
a0f9b09
to
241d6ca
Compare
lgtm ACK 241d6ca |
…ub Actions 241d6ca ci: Disable cache save for pull requests in GitHub Actions (Hennadii Stepanov) Pull request description: This PR disable cache save for pull requests in GitHub Actions. Otherwise, multiple pull requests fill GitHub Actions cache quota shortly. See a discussion [here](bitcoin#28187 (comment)). --- **NOTE** for the maintainers with "owner" permissions. This PR needs the `actions/cache/restore@*` and `actions/cache/save@*` acrions to be explicitly allowed in the repository's Actions permissions. ACKs for top commit: MarcoFalke: lgtm ACK 241d6ca Tree-SHA512: a7786c7ec99bfa6991bf6ae08fd7ed3546e8c5d083a1b2bae7638f6f31e77fdf2cf4fc69d85834faf87f98db1f4a82026ce1dc5fc1bc6650e8bf1c09bf7e90f5
This PR disable cache save for pull requests in GitHub Actions.
Otherwise, multiple pull requests fill GitHub Actions cache quota shortly.
See a discussion here.
NOTE for the maintainers with "owner" permissions.
This PR needs the
actions/cache/restore@*
andactions/cache/save@*
acrions to be explicitly allowed in the repository's Actions permissions.