feat(ci): no more docker builds on PR-related events #27146
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
mistercrunch
requested review from
villebro,
geido,
eschutho,
rusackas,
betodealmeida,
nytai,
craig-rueda,
john-bodley,
kgabryje and
dpgaspar
as code owners
github-actions
bot
added
the
github_actions
|
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 |
3 tasks
|
I agree @craig-rueda and adapted to run the "ci" build preset on pull_request, this will only |
9 tasks
sfirke
pushed a commit
to sfirke/superset
that referenced
this pull request
Mar 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
masteras 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.