-
Notifications
You must be signed in to change notification settings - Fork 1k
run our docker ci on gha runners directly #17442
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
base: main
Are you sure you want to change the base?
Conversation
f0bc2ba
to
5a0d26c
Compare
1311420
to
095c511
Compare
095c511
to
b7dd6e8
Compare
zizmor errors can probably be resolved easily with https://gha-update.readthedocs.io/ |
#18103 should unblock this |
Signed-off-by: Mike Fiedler <[email protected]>
Signed-off-by: Mike Fiedler <[email protected]>
save: true | ||
context: . | ||
cache-from: type=gha | ||
cache-to: type=gha,mode=max |
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 think we need something like:
cache-to: type=gha,mode=max | |
cache-to: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name != github.repository && '' || 'type=gha,mode=max' }} |
Otherwise action runs on PRs from untrusted forks can overwrite this cache as well.
(cc @woodruffw, should zizmor flag this?)
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.
Huh yeah, it should -- I'm actually confused as to why it didn't, since I have a coordinate for the push: true
part of this:
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.
Oh never mind, I see why it didn't: it considers docker/build-push-action
a "publish sink" but not a "cache source" at the moment, since I'm only detecting push: true
and not the cache-to: ...
field.
This is a shortcoming in the current audit, I'll file an issue 🙂
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.
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.
Awesome, thanks! Just to confirm, this suggestion resolves the issue, correct?
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 think so, although I'm murky on whether doing the same for cache-from
is also needed: that's a sink rather than a source so I think it's okay, but I might be missing something.
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 think we specifically want cache-from
to always be permitted here, so PRs can take advantage of our central cache to speed up builds (but can't write to it).
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.
Makes sense!
var-lib-apt | ||
root-cache-pip | ||
root-npm | ||
key: cache-${{ hashFiles('Dockerfile') }} |
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.
key: cache-${{ hashFiles('Dockerfile') }} | |
key: cache-${{ hashFiles('Dockerfile') }} | |
lookup-only: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name != github.repository }} |
https://github.com/actions/cache/blob/5a3ec84eff668545956fd18022155c47e93e2684/README.md?plain=1#L78
Signed-off-by: Mike Fiedler <[email protected]>
No description provided.