[SPARK-57074][INFRA] Skip Build workflow on fork master pushes#56117
Closed
zhengruifeng wants to merge 1 commit into
Closed
[SPARK-57074][INFRA] Skip Build workflow on fork master pushes#56117zhengruifeng wants to merge 1 commit into
zhengruifeng wants to merge 1 commit into
Conversation
Adds a job-level `if:` guard on `build_main.yml` so that pushes to `master` on a fork (e.g. clicking the "Sync fork" button) do not trigger the full build. Upstream pushes and pushes to non-master branches on forks are unaffected. Generated-by: Claude Code (claude-opus-4-7)
92e6b02 to
41ce0f2
Compare
HyukjinKwon
approved these changes
May 27, 2026
zhengruifeng
added a commit
that referenced
this pull request
May 27, 2026
### What changes were proposed in this pull request? Add a job-level `if:` guard on `.github/workflows/build_main.yml` so that the `Build` workflow does not run on pushes to `master` on a fork: ```yaml if: github.repository == 'apache/spark' || github.ref != 'refs/heads/master' ``` ### Why are the changes needed? When a contributor clicks the "Sync fork" button on their fork's `master` (which mirrors `apache/spark`), GitHub records it as a push to `master` and fires `build_main.yml`, running the entire build/test matrix on the fork — duplicating work that already ran upstream. The pattern is already used in the per-branch workflows (`build_branch*.yml` gate with `if: github.repository == 'apache/spark'`); this extends the same idea to `build_main.yml`, but only for the `master` branch on forks so that dev branches on forks continue to be tested. Behavior after this change: | Where | Action | Branch pushed | Job runs? | |---|---|---|---| | `apache/spark` | any push | any | runs (unchanged) | | fork | click "Sync fork" on master page | `master` | **skipped** | | fork | push to dev branch | `<dev-branch>` | runs | | fork | merge `upstream/master` into dev branch, push | `<dev-branch>` | runs | | fork | rebase dev branch on `upstream/master`, force-push | `<dev-branch>` | runs | | fork | push directly to fork's `master` | `master` | **skipped** | The guard is purely branch-name-based — only the literal ref `refs/heads/master` is suppressed. A branch named `master-foo` or `branch-4.x` is unaffected. ### Does this PR introduce _any_ user-facing change? No. CI behavior only. ### How was this patch tested? Inspected the condition manually against each scenario in the table above: - `github.repository == 'apache/spark'` — first clause true → runs. - Fork, `github.ref == 'refs/heads/master'` — both clauses false → skipped. - Fork, `github.ref == 'refs/heads/<dev-branch>'` — second clause true → runs (covers rebases against upstream master and merges of upstream master into a dev branch, since those still push to the dev branch ref). ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-4-7) Closes #56117 from zhengruifeng/skip-fork-master-build-dev6. Authored-by: Ruifeng Zheng <ruifengz@apache.org> Signed-off-by: Ruifeng Zheng <ruifengz@foxmail.com> (cherry picked from commit 8f22a4b) Signed-off-by: Ruifeng Zheng <ruifengz@foxmail.com>
Contributor
Author
|
thanks, merged to master/4.x |
This file contains hidden or 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
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.
What changes were proposed in this pull request?
Add a job-level
if:guard on.github/workflows/build_main.ymlso that theBuildworkflow does not run on pushes tomasteron a fork:Why are the changes needed?
When a contributor clicks the "Sync fork" button on their fork's
master(which mirrorsapache/spark), GitHub records it as a push tomasterand firesbuild_main.yml, running the entire build/test matrix on the fork — duplicating work that already ran upstream. The pattern is already used in the per-branch workflows (build_branch*.ymlgate withif: github.repository == 'apache/spark'); this extends the same idea tobuild_main.yml, but only for themasterbranch on forks so that dev branches on forks continue to be tested.Behavior after this change:
apache/sparkmaster<dev-branch>upstream/masterinto dev branch, push<dev-branch>upstream/master, force-push<dev-branch>mastermasterThe guard is purely branch-name-based — only the literal ref
refs/heads/masteris suppressed. A branch namedmaster-fooorbranch-4.xis unaffected.Does this PR introduce any user-facing change?
No. CI behavior only.
How was this patch tested?
Inspected the condition manually against each scenario in the table above:
github.repository == 'apache/spark'— first clause true → runs.github.ref == 'refs/heads/master'— both clauses false → skipped.github.ref == 'refs/heads/<dev-branch>'— second clause true → runs (covers rebases against upstream master and merges of upstream master into a dev branch, since those still push to the dev branch ref).Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (claude-opus-4-7)