Repository navigation
Commit 8c8a222
committed
[SPARK-60578][INFRA] Migrate build status workflow off of
### What changes were proposed in this pull request?
Remove `notify_test_workflow.yml` and rely on the existing `update_build_status.yml` to report fork build status on PRs. Update the comments accordingly.
This builds on [#58579](#58579) (SPARK-59293), which fixes errors that abort the scheduled scan.
### Why are the changes needed?
ASF is disabling the `pull_request_target` trigger in [November 2026][asf], ahead of GitHub's [December 2 deadline][github]. This is our only workflow using it.
The scheduled updater already creates missing `Build` checks (SPARK-58660), so we don't need another workflow to replace the notifier. Fork builds still run on push, as usual; this PR only changes how their status gets reported.
We should backport this PR to active maintenance branches that accept PRs, since `pull_request_target` uses the base branch's workflow.
[asf]: https://infra.apache.org/github-actions-policy.html
[github]: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target#default-policy-for-pull_request_target
I intentionally kept this PR simple as I _really_ don't like that we have to maintain so much GitHub Actions-specific JavaScript just to manage our fork-based contribution workflow.
In other words, in the interest of simplicity I intentionally left out:
- Any mechanism to update PRs "live".
- Testing infrastructure for these workflows and the JavaScript they contain.
This infrastructure is not in the Spark project's area of expertise. It really feels like something we should be able to import and use from somewhere. Until then, I think we should strive to keep these workflows as simple as possible.
### Does this PR introduce _any_ user-facing change?
No, nothing for end users.
For contributors here on GitHub:
- The "Notify test workflow" check goes away.
- New `Build` checks appear as `queued` on the first scheduled pass and pick up the fork result on the next. The schedule is every 15 minutes, but GitHub can delay or drop runs.
- If you push multiple updates to a PR between scans, only the latest commit gets a `Build` check.
- The results link opens the fork's Actions run instead of its `Run / Check changes` check.
### How was this patch tested?
Checked locally with actionlint, YAML parsing, and git diff --check.
`update_build_status.yml` changes only comments, so the scheduled updater, which runs from master, already behaves as it will after this PR. In [run 40517915808](https://github.com/apache/spark/actions/runs/40517915808) it created Build checks for PRs that had none (#54953, #59831), and later scheduled runs synced them (#54953 is now success).
Additionally, an agent replayed the unmodified updater against 150 open PRs with their Build checks hidden and writes intercepted: all 150 resolve to the same fork run, and the 36 action_required PRs would get identical checks. All 708 open master PRs currently have exactly one Build check, and 706 match their fork run.
This PR can't fully test itself because `pull_request_target` runs the base branch's copy of the notifier. I will run additional tests post merge.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Copilot SDK in VS Code (version unavailable)
Closes #59829 from nchammas/pr-target-actions-policy.
Authored-by: Nicholas Chammas <[email protected]>
Signed-off-by: Nicholas Chammas <[email protected]>
(cherry picked from commit 6a02fc4)
Signed-off-by: Nicholas Chammas <[email protected]>pull_request_target trigger1 parent d7355a7 commit 8c8a222
1 file changed
Lines changed: 0 additions & 152 deletions
This file was deleted.
0 commit comments