ci(fork): drop the edited trigger, it can clear a red PR by omegent-app[bot] · Pull Request #365 · patroza/t3code

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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>

omegent-app · 2026-08-06T10:44:10Z

Reverts the edited half of #359. My change, my
bug — and it is a merge-gate bypass, so it should go in ahead of the other open PRs.

What I got wrong

#359 added edited to the pull_request activity types so retargeting a PR would run CI, with a
job-level if guard skipping edits that did not move the base. I reasoned the guard would keep the
cost 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:

Check skipping
Mobile Native Static Analysis skipping
Release Smoke skipping
Test skipping

with mergeable: MERGEABLE, mergeStateStatus: CLEAN. Every required check satisfied by a run that
executed nothing.

Change

Drop edited and the four job guards. Keep ready_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 fires reopened, which is
watched. 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

#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

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

patroza enabled auto-merge (squash) August 6, 2026 10:48

patroza disabled auto-merge August 6, 2026 10:48

patroza merged commit 8750458 into fork/devAug 6, 2026
5 checks passed

Conversation

omegent-appBot commented Aug 6, 2026

What I got wrong

Change

What this gives up

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What I got wrong

Change

What this gives up

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What I got wrong

Change

What this gives up

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What I got wrong

Change

What this gives up

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What I got wrong

Change

What this gives up

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What I got wrong

Change

What this gives up