-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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(ci): no more docker builds on PR-related events #27146
Conversation
Speaking with the devexp committee, and in the recent community hall meeting, it's pretty clear we don't need to build the whole docker matrix on every PR event. It's somewhat expensive and isn't useful. One of the reason we did it, from what I've gathered, is we want to catch if some change breaks the docker build for whatever reason. Now we may not need to actively prevent this pre-merge as this is unlikely, yet we can still catch it on `master` as I'm keeping the push events on master. Note that: - I'm also moving the master push build to be multi-platform (amd+arm) as we started doing this for the release builds, which is nice as the same image can be used on different archs - The PR events were not "pushed" or cached in our shared, remote dockerhub-hosted repo anyways, they were just kind of dry-runs Oh one more thing, notice the no-op.yml changes? That's because the required checks related to branch protection are always based on what's defined on .asf.yml ON `master`, meaning i need to add dummy/no-op checks to get this merged, and those can be cleaned up later on in a follow up PR. Let me know if you know a better way to deal with this.
How will users be able to test Dockerfile changes without running anything at all? I agree that the whole matrix probably doesn't need to be built, but what's stopping us from just allowing one path at a min to run? We could also remove it from the "required" checks as to not be a blocker |
I agree @craig-rueda and adapted to run the "ci" build preset on pull_request, this will only |
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
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.
SUMMARY
Speaking with the devexp committee, and in the recent community hall
meeting, it's pretty clear we don't need to build the whole docker
matrix on every PR event. It's somewhat expensive and isn't useful.
One of the reason we did it, from what I've gathered, is we want to
catch if some change breaks the docker build for whatever reason. Now
we may not need to actively prevent this pre-merge as this is unlikely,
yet we can still catch it on
master
as I'm keeping the push events onmaster.
Note that:
as we started doing this for the release builds, which is nice as
the same image can be used on different archs
dockerhub-hosted repo anyways, they were just kind of dry-runs
Oh one more thing, notice the no-op.yml changes? That's because the
required checks related to branch protection are always based on what's
defined on .asf.yml ON
master
, meaning i need to add dummy/no-opchecks to get this merged, and those can be cleaned up later on in a
follow up PR. Let me know if you know a better way to deal with this.