ci(fork): run PR checks when a PR is retargeted or marked ready by omegent-app[bot] · Pull Request #359 · patroza/t3code

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T08:53:16Z

Fixes the cause of #357 sitting on four required checks
that could never report.

What happened

pull_request defaults to the activity types opened, synchronize, reopened. #357's timeline:

Event	Activity type	Result
force-pushed while base was `fork/discord`	`synchronize`	filtered — #348 removed the overlay bases from this workflow's `branches` list
base changed `fork/discord` → `fork/dev`	`edited`	not a default type
marked ready for review	`ready_for_review`	not a default type

So the PR never emitted a watched event while sitting on a watched base. Zero fork-ci runs existed
for its head SHA, the four required checks stayed Expected — Waiting for status to be reported, and
auto-merge waited on something that had no way to arrive. Toggling draft/ready and re-enabling
auto-merge could not help, because none of those are trigger types either.

Change

List the activity types explicitly and add both missing ones:

types: [opened, synchronize, reopened, ready_for_review, edited]

edited also fires for title and body edits, which happen constantly here and must not spend a
full CI run including a macOS runner. github.event.changes.base is populated only when the base
actually changed, so each job skips an edit that did not move the base.

Unblocking #357 itself

Closed and reopened it — reopenedis a default type, so it fires against the current base
without adding a commit to the branch. Checks are running there now.

Scope

I checked every open PR on fork/dev: only #357 was affected. The others were based on
fork/changes, which is still in the branches list, so their pushes did produce runs. This was
specifically a PR that had been sitting on an overlay base when those bases were removed — a
transitional hazard from the drain, but one worth closing since a required check that can never
report is indistinguishable from a hung CI system.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

#357 sat on four required checks that could never report. It was opened against fork/discord, force-pushed, then retargeted to fork/dev and marked ready — and none of those produced a run. The default pull_request activity set is opened, synchronize and reopened. The force-push was a synchronize, but the base was still fork/discord, which #348 removed from this workflow's branch list, so it was filtered out. Retargeting fires "edited", and marking ready fires "ready_for_review"; neither is in the default set. The PR therefore never emitted a watched event while sitting on a watched base, and auto-merge waited on checks that had no way to arrive. List the activity types explicitly and add both missing ones. "edited" also fires for title and body edits, which happen constantly and must not spend a full CI run including a macOS runner. github.event.changes.base is populated only when the base actually changed, so each job skips an edit that did not move the base. Unblocking the PR itself needed a close and reopen: "reopened" is in the default set, so it fires against the current base without adding a commit. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

@patroza

Reverts the `edited` half of [#359](#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](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

patroza enabled auto-merge (squash) August 6, 2026 08:55

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

omegent-appBot mentioned this pull request Aug 6, 2026
ci(fork): drop the edited trigger, it can clear a red PR #365
Merged

Conversation

omegent-appBot commented Aug 6, 2026

What happened

Change

Unblocking #357 itself

Scope

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What happened

Change

Unblocking #357 itself

Scope

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What happened

Change

Unblocking #357 itself

Scope

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What happened

Change

Unblocking #357 itself

Scope

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

What happened

Change

Unblocking #357 itself

Scope

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant