Trigger the merge sync from an event that actually reaches this file (dev-branch)

[darksidemilk]

Fixes a bug in #1160: the stub never actually fired

Corrects the trigger on .github/workflows/sync-generated-files.yml. My mistake in #1160, caught by checking whether it had run.

What happened

The stub added in #1160 has not run once. Four PRs merged into working-1.6 since it landed (#1162, #1163, #1164, #1165) and it produced no runs — it didn't even appear in the repository's Actions workflow list:

$ gh api repos/FOGProject/fogproject/actions/workflows
.github/workflows/tests.yml            [active]
Check FOG version                      [disabled_manually]

working-1.6 is currently 1.6.0-beta.3572 where fog-version.sh says it should be 1.6.0-beta.3588 — 16 commits stale, waiting for the daily sweep, which is exactly the gap #1160 was meant to close.

Why

pull_request_target is read from the repository's default branch — stable — not from the PR's base branch. GitHub documents it directly: "runs in the context of the default branch of the base repository." That's the general rule for most events; push and create are the exceptions that resolve per-ref. So a copy living on working-1.6/dev-branch is never consulted, no matter how correct its contents.

I reasoned from tests.yml as precedent, which was wrong: that uses pull_request, evaluated from the head-into-base merge ref. That's exactly why one copy per base branch works there, and why it works without a copy on stable.

The fix

pull_request: types: [closed] — read from the base branch, so it reaches this file where it already lives.

The alternative, putting the stub on stable, does work and gives fuller coverage. It was rejected because only stable's copy would ever execute: editing this file on working-1.6 would silently do nothing, and every future change to sync behaviour would need a PR into the release branch.

What that costs

Fork PRs. pull_request withholds secrets from forks, and the reusable workflow needs FOG_WORKFLOWS_PRIVATE_KEY to mint its App token — so a merged fork PR would fail rather than sync. The added same-repo guard skips those, and the daily sweep picks them up. That's the same gap, and the same backstop, that direct pushes already rely on — and a gap the schedule already covers beats a red X on every external contribution.

Unchanged

Still pull_request-family rather than push, so the bot's own fixup push cannot re-fire it and the 2026-07-28 loop stays closed. Still the same branch allowlist keeping rc-*/feature-* on the schedule. Still no logic in this repo.

The header now records why pull_request_target is wrong here, so nobody switches it back on the reasonable-looking grounds that it's the variant which gets fork secrets.

Verification

actionlint clean; trigger and guard confirmed by parsing the file. The real proof is the next merged PR: it should produce a Sync generated files and version run, and that run's own push should queue no second run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK