rusackas opened a new pull request, #42504:
URL: https://github.com/apache/superset/pull/42504
### SUMMARY
Adds automation to apply the existing `requires:rebase` label ("Requires
rebasing on top of current master") to open PRs that GitHub reports as
`CONFLICTING`, and remove it once a rebase makes the PR mergeable again. The
label already exists in the repo but nothing currently applies it — this is
meant to make it possible to filter the ~400-PR backlog down to "PRs that
actually need attention before they can be reviewed," using
[`eps1lon/actions-label-merge-conflict`](https://github.com/eps1lon/actions-label-merge-conflict).
### Design notes (please sanity-check the cadence choice)
The action always re-checks **every open PR** in the repo via a paginated
GraphQL query on every run, regardless of what triggered it (confirmed by
reading its source — there's no "just check this one PR" mode). The project's
own README suggests triggering on `push` (to the default branch) plus
`pull_request_target: [synchronize]`. For most repos that's fine, but on a repo
with Superset's merge/push volume that combination means a full open-PR-backlog
sweep on *every* merge to `master` and *every* push to *any* open PR — many
times an hour.
Instead this runs on a `schedule` (every 2 hours) plus `workflow_dispatch`
for manual runs. Same end result for triage purposes (the label doesn't need to
update within seconds of a conflict appearing), but bounded to 12 sweeps/day
instead of being proportional to the repo's push volume. Flagging this as a
deliberate deviation from the upstream example in case there's a reason to want
it more (or less) real-time than that — trivial to adjust the cron.
Also deliberately **not** using `commentOnDirty`/`commentOnClean`: the label
is the whole signal (matches its existing description), and posting a comment
on every currently-conflicting PR the first time this runs would be a burst of
notification noise across the existing backlog.
One small bonus: wired up `removeOnDirtyLabel: "need:merge"` — if a PR was
marked ready-to-merge and then drifts into conflict, this strips that stale
signal so reviewers don't act on a "ready to merge" label that's no longer true.
### Requires an ASF Infra ticket
Same allowlist process this repo already follows for other third-party
actions (see the equivalent comment for `lychee-action` added in #42501):
`eps1lon/actions-label-merge-conflict` isn't used anywhere in this repo today,
so this job will likely fail to start with an "action is not allowed" error
until it's added to the org's allowlist. Filing that ticket is probably the
real next step here.
### TESTING INSTRUCTIONS
1. Get `eps1lon/actions-label-merge-conflict` allowlisted for
`apache/superset` (ASF Infra ticket).
2. Trigger the workflow manually via `workflow_dispatch` and confirm it runs
without errors.
3. Spot-check a few PRs: one with a known conflict should pick up
`requires:rebase`; a clean one should not (and should have the label removed if
it was previously conflicting).
4. Confirm a PR carrying `need:merge` that's also conflicting loses that
label.
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
