Say pull_request, because pull_request_target never fired - #20
Merged
Conversation
#17 described the merge entry point as `pull_request_target: closed`. That was what fogproject's stub used, and it did not work: GitHub reads a `pull_request_target` workflow from the repository's DEFAULT branch, `stable`, rather than from the pull request's base branch, so a stub living on working-1.6/dev-branch was never consulted. It never registered as a workflow at all, and four PRs merged into working-1.6 without it running. fogproject has moved the stub to `pull_request: types: [closed]`, which is read from the base branch and so reaches the file where it actually lives. This brings the description here back in line with what the caller does. Records why, not just what. `pull_request_target` is the obvious-looking choice -- it is the variant that gets secrets on a fork PR -- so without the reason written down the natural next move is to switch it back. The cost of `pull_request` is that a merged fork PR has no secrets and is skipped by the stub's same-repo guard; the schedule already covers those, as it does direct pushes. Adds a second standing rule alongside the trigger-safety one, because they are different questions and only the first was written down. The safety question is "can the bot's own push raise this event". The new one is "which ref is this trigger read from" -- most events, including pull_request_target, schedule and workflow_dispatch, are read only from the default branch, while push, create and pull_request resolve per-ref. A workflow that is correct but never runs is indistinguishable from one that ran and found nothing to do, which is exactly how this went unnoticed, so the rule ends by saying to confirm a new trigger actually produced a run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK
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.
What
#17 described the merge entry point as
pull_request_target: closed. That is what fogproject's stub used, and it did not work.GitHub reads a
pull_request_targetworkflow from the repository's default branch (stable), not from the PR's base branch — so a stub living onworking-1.6/dev-branchwas never consulted. It never registered as a workflow at all, and four PRs merged intoworking-1.6without it running.fogproject has moved the stub to
pull_request: types: [closed](FOGProject/fogproject#1171, #1172), which is read from the base branch and so reaches the file where it actually lives. This brings the description here back in line with what the caller does.Why it records the reason and not just the fact
pull_request_targetis the obvious-looking choice — it is the variant that gets secrets on a fork PR — so without the reason written down, the natural next move is to switch it back. The cost ofpull_requestis that a merged fork PR has no secrets and is skipped by the stub's same-repo guard; the schedule already covers those, exactly as it covers direct pushes.New standing rule
Adds a second rule alongside the trigger-safety one, because they're different questions and only the first was written down:
pull_request_target,scheduleandworkflow_dispatch, are read only from the default branch;push,createandpull_requestresolve per-ref.It ends by saying to confirm a new trigger actually produced a run — because a workflow that is correct but never runs is indistinguishable from one that ran and found nothing to do, which is precisely how this went unnoticed.
Verified
actionlintclean. No behavioural change in this repo — comments and CLAUDE.md only.🤖 Generated with Claude Code
https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK