You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, I believe the scope for runs-on/cache replicates the same restrictions as actions/cache for accessing a cache. This is a simple way to enforce control flow for the provenance and propagation of cached assets, e.g. for cache isolation to avoid unintended cross talk between PRs or for security to avoid cache poisoning from untrusted or public PRs.
However, for private orgs using poly repo source layouts, it would be nice to selectively specify for CI workflows for one repo to restore caches from another repo. Take for example the case where we have one integration repo and many smaller feature repos on a private GitHub org. The CI for the integration repo regularly rebuilds everything, including all other feature repos. While the CI for feature repos usually only build themselves and some subset of other feature repos.
When occasionally opening a PR to a feature repo, it would be nice to have the cache action fallback and restore from a target branch from the remote integration repo, rather than starting from a cold cache if such were locally evicted due to last accessed age, or divergence from upstream. This could be made to mimic the existing levels of scope for branches, but on a multi-repo level, with the integration repo being the ultimate fallback, rather than just the default branch on the feature repo itself.
I briefly looked into if it was feasible to replicate such control flow out-of-band by using symlinks in the S3 bucket, but that doesn't seem viable with S3 alone:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
By default, I believe the scope for
runs-on/cache
replicates the same restrictions asactions/cache
for accessing a cache. This is a simple way to enforce control flow for the provenance and propagation of cached assets, e.g. for cache isolation to avoid unintended cross talk between PRs or for security to avoid cache poisoning from untrusted or public PRs.However, for private orgs using poly repo source layouts, it would be nice to selectively specify for CI workflows for one repo to restore caches from another repo. Take for example the case where we have one integration repo and many smaller feature repos on a private GitHub org. The CI for the integration repo regularly rebuilds everything, including all other feature repos. While the CI for feature repos usually only build themselves and some subset of other feature repos.
When occasionally opening a PR to a feature repo, it would be nice to have the cache action fallback and restore from a target branch from the remote integration repo, rather than starting from a cold cache if such were locally evicted due to last accessed age, or divergence from upstream. This could be made to mimic the existing levels of scope for branches, but on a multi-repo level, with the integration repo being the ultimate fallback, rather than just the default branch on the feature repo itself.
I briefly looked into if it was feasible to replicate such control flow out-of-band by using symlinks in the S3 bucket, but that doesn't seem viable with S3 alone:
Perhaps a reverse proxy could be used redirect requests with a given marker identifier, e.g.
::org_name/repo_name::
?I'm not insisting this be officially supported, but it would be nice to implement on my own AWS backend.
Beta Was this translation helpful? Give feedback.
All reactions