dongjoon-hyun commented on code in PR #57867:
URL: https://github.com/apache/spark/pull/57867#discussion_r3744937414
##########
.github/workflows/update_build_status.yml:
##########
@@ -122,8 +186,162 @@ jobs:
details_url: run.data.details_url
})
}
+ }
+ }
+
+ // No syncable Build check: notify_test_workflow.yml never
created one, or only
+ // a stale action_required one exists. Recreate it here,
mirroring notify. Skip
+ // if the head repo was deleted.
+ if (!syncableBuildCheck && pr.head.repo) {
+ const forkOwner = pr.head.repo.owner.login
+ const forkRepo = pr.head.repo.name
+ // Look up the fork's build_main.yml runs for the PR
branch, matching
+ // notify_test_workflow.yml. Filter by branch (head.ref),
not just head_sha:
+ // build_main.yml skips fork pushes to master (the "Sync
fork" case), so the
+ // same SHA can carry a skipped/unrelated run on another
branch, and a
+ // head_sha-only lookup could attach the Build check to
that run instead of
+ // the PR branch's. Then pick the run whose head_sha
equals the settled head
+ // SHA so stale runs from earlier commits on the branch
cannot drive the
+ // decision. Re-poll a few times: the run is often not yet
registered right
+ // after a push, and we must not create the sticky
action_required check below
+ // over registration lag. A transient lookup error (5xx,
network, rate limit)
+ // aborts to a later scheduled pass; any other error is
treated as "no runs".
+ let matched_run
+ let transient = false
+ for (let attempt = 0; attempt < 3; attempt++) {
Review Comment:
Once a PR already carries an `action_required` Build check (Actions disabled
in the fork, old master, etc.), it never becomes syncable, so every 15-minute
pass re-enters this backfill branch: up to 3 fork-run lookups plus two 3-second
sleeps, plus the recheck listing, indefinitely until the PR is closed. With a
few dozen such PRs, each scheduled run stretches by minutes and consumes rate
limit.
The re-polling only exists to avoid creating a sticky `action_required`
check over registration lag. When the initial `checkRuns` listing already shows
an `action_required` Build check, that risk is gone, so a single lookup with no
retries/sleeps would suffice there, while still promoting it to a `queued`
check on whichever pass first sees a run appear.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
