The scheduled gh-aw workflows (PR Tooling Safety Check, the LabelOps pair, Regression PR Shepherd, Repo Assist, Agentic Workflow Auto-Update, etc.) run on schedule: with no guard against running on forks. The activation job has no if: github.repository == 'dotnet/fsharp', so on any fork the cron fires and the job dies a few seconds later at the "Validate COPILOT_GITHUB_TOKEN secret" step, since forks don't have that secret.
The practical effect: anyone who forks the repo and stays active gets a failed-workflow email for every cron tick, across all of these workflows. That's several per hour. GitHub only auto-disables scheduled workflows on forks that have been inactive for 60 days, so active forks (i.e. anyone with an open or in-progress contribution) keep getting spammed.
The usual fix is a repository guard on the scheduled entry point, e.g.:
jobs:
activation:
if: github.repository == 'dotnet/fsharp'I'm guessing gh-aw has a config knob for this in the .md source rather than hand-editing the compiled .lock.yml, but I haven't dug into it. Flagging it since it's easy to miss from inside the main repo where the secret exists and everything's green.
In the meantime, forkers can work around it with gh workflow disable <id> on each one.
The scheduled
gh-awworkflows (PR Tooling Safety Check, the LabelOps pair, Regression PR Shepherd, Repo Assist, Agentic Workflow Auto-Update, etc.) run onschedule:with no guard against running on forks. Theactivationjob has noif: github.repository == 'dotnet/fsharp', so on any fork the cron fires and the job dies a few seconds later at the "Validate COPILOT_GITHUB_TOKEN secret" step, since forks don't have that secret.The practical effect: anyone who forks the repo and stays active gets a failed-workflow email for every cron tick, across all of these workflows. That's several per hour. GitHub only auto-disables scheduled workflows on forks that have been inactive for 60 days, so active forks (i.e. anyone with an open or in-progress contribution) keep getting spammed.
The usual fix is a repository guard on the scheduled entry point, e.g.:
I'm guessing gh-aw has a config knob for this in the
.mdsource rather than hand-editing the compiled.lock.yml, but I haven't dug into it. Flagging it since it's easy to miss from inside the main repo where the secret exists and everything's green.In the meantime, forkers can work around it with
gh workflow disable <id>on each one.