A merge to staging that does not trigger Deploy Staging produces no signal at all

[jorgecuesta]

A merge to staging that does not trigger Deploy Staging produces no signal at all

What happened

PR #338 was merged to staging on 2026-08-13 at 22:05:37Z with the release label present. No Deploy Staging run was created — not a failed one, not a skipped one, nothing. Three minutes later the Actions list still showed only the CI run from before the merge.

Because post-deploy is what merges staging into release, the release branch silently stayed one commit behind, and the open release PR did not include the fix. Merging that release PR at that moment would have shipped v0.16.0 without it. This was caught by chance, while watching for the run to appear.

Why it did not fire

#330 changed the trigger from pull_request to pull_request_target to fix fork-PR deploys. That change lives on staging. GitHub's rule for this event:

This event runs in the context of the default branch of the base repository … This event will only trigger a workflow run if the workflow file exists on the default branch.

main still carried the old pull_request version, because the change was sitting in the unmerged release PR. So pull_request_target did not exist where GitHub looks for it, and the event matched nothing.

It is a chicken-and-egg: the trigger that keeps release in sync could not work until a release reached main, and reaching main depends on release being in sync. It was unblocked by dispatching Deploy Staging manually (gh workflow run deploy-staging.yml --ref staging), which is also how the previous staging deploy on 2026-07-30 ran.

main now carries pull_request_target (as of v0.16.0), so the immediate condition is resolved.

The part worth fixing

The specific cause is gone; the failure mode is not. A merge to staging that triggers nothing is indistinguishable from a healthy quiet period:

• no run appears, so there is nothing red to notice,
• no notification fires,
• the only symptom is release drifting behind staging, which nobody looks at until a release is cut,
• and the consequence is shipping a release missing whatever was merged in the meantime.

Two directions, either or both:

• Verify it once, deliberately. The next merge to staging should be watched to confirm a run is actually created. Right now this is assumed, not demonstrated.
• Make the drift itself the alarm. A cheap scheduled check that fails when release is behind staging by more than one merge would turn a silent gap into a visible one, independently of why the trigger did or did not fire.

Context

Surfaced while shipping v0.16.0 on 2026-08-13.