ci(fork): drop the edited trigger, it can clear a red PR - #365
Merged
Conversation
#359 added "edited" to the pull_request activity types so that retargeting a PR would run CI, with a job-level guard skipping edits that did not move the base. The guard is worse than not triggering at all. A job skipped by an if condition still publishes a check run, GitHub counts a skipped required check as satisfied, and the skipped run supersedes the real one. Editing the title or body of a PR whose checks had failed therefore replaces those failures with skipped runs and leaves it mergeable. Observed on #364: after a body edit, all four required checks read "skipping" and mergeStateStatus was CLEAN. Keep ready_for_review, which is what actually fixed the case #359 was opened for: #357 was marked ready after being retargeted, and nothing fired. Retargeting without a push no longer triggers CI. That is rarer now that overlays are gone and everything targets fork/dev, and it is recoverable -- close and reopen fires "reopened", which is watched. A gap that needs a deliberate action to work around is better than a bypass that needs a title edit to trigger. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>
patroza
enabled auto-merge (squash)
August 6, 2026 10:48
patroza
disabled auto-merge
August 6, 2026 10:48
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
1 participant
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.
Reverts the
editedhalf of #359. My change, mybug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.
What I got wrong
#359 added
editedto thepull_requestactivity types so retargeting a PR would run CI, with ajob-level
ifguard skipping edits that did not move the base. I reasoned the guard would keep thecost down. It does — but a skipped job still publishes a check run, GitHub counts a skipped
required check as satisfied, and the skipped run supersedes the real one.
So editing the title or body of a PR whose checks had failed replaces those failures with skipped
runs and leaves it mergeable.
Observed live on #364 — I edited the body, and:
with
mergeable: MERGEABLE,mergeStateStatus: CLEAN. Every required check satisfied by a run thatexecuted nothing.
Change
Drop
editedand the four job guards. Keepready_for_review, which is what actually fixed the case#359 was opened for: #357 had been retargeted and then marked ready, and nothing fired.
What this gives up
Retargeting without a push no longer triggers CI. That is rarer now that overlays are gone and
everything targets
fork/dev, and it is recoverable — close and reopen firesreopened, which iswatched. That is how #357 was unblocked in the first place.
A gap that needs a deliberate action to work around beats a bypass that needs a title edit to
trigger.
Co-authored by @patroza
opened by Patrick Roza in chat thread Discord · Discord · T3