The autoupdate workflow (.github/workflows/autoupdate.yml) authenticated its branch-update pushes with the default GITHUB_TOKEN. Pushes made with GITHUB_TOKEN do not re-trigger downstream workflow runs, so status checks were never re-run on the PR branches that autoupdate updated.
This switches the token to the STATUS_CHECKS_RETRIGGER_TOKEN PAT (a personal access token with the right scopes) so autoupdate's pushes do re-trigger downstream status checks.
Changes (only .github/workflows/autoupdate.yml)
Add environment: production to the autoupdate job so the environment-scoped secret is accessible.
Source the token from ${{ secrets.STATUS_CHECKS_RETRIGGER_TOKEN }} instead of ${{ secrets.GITHUB_TOKEN }}. The action still reads its token from the GITHUB_TOKEN env var — only the value changes.
Update the explanatory comment to reflect that a PAT is now used specifically so autoupdate pushes re-trigger checks.
Action remains pinned to its existing commit SHA; permissions and PR_FILTER are unchanged.
Validation
YAML parses: python -c "import yaml;yaml.safe_load(open('.github/workflows/autoupdate.yml'));print('ok')" → ok
No unit-testable code here — this is workflow YAML only.
⚠️ Caveat: production environment protection rules
Adding environment: production means the job now runs in that environment. If the production environment has deployment protection rules (required reviewers or a wait timer), the autoupdate job will PAUSE for approval on every push to main, which would stall autoupdate entirely. Please confirm the production environment has no blocking protection rules for this use before/after merging.
## Summary
The `autoupdate` workflow (`.github/workflows/autoupdate.yml`) authenticated its branch-update pushes with the default `GITHUB_TOKEN`. Pushes made with `GITHUB_TOKEN` do **not** re-trigger downstream workflow runs, so status checks were never re-run on the PR branches that autoupdate updated.
This switches the token to the `STATUS_CHECKS_RETRIGGER_TOKEN` PAT (a personal access token with the right scopes) so autoupdate's pushes **do** re-trigger downstream status checks.
### Changes (only `.github/workflows/autoupdate.yml`)
- Add `environment: production` to the `autoupdate` job so the environment-scoped secret is accessible.
- Source the token from `${{ secrets.STATUS_CHECKS_RETRIGGER_TOKEN }}` instead of `${{ secrets.GITHUB_TOKEN }}`. The action still reads its token from the `GITHUB_TOKEN` env var — only the value changes.
- Update the explanatory comment to reflect that a PAT is now used specifically so autoupdate pushes re-trigger checks.
- Action remains pinned to its existing commit SHA; `permissions` and `PR_FILTER` are unchanged.
### Validation
- YAML parses: `python -c "import yaml;yaml.safe_load(open('.github/workflows/autoupdate.yml'));print('ok')"` → `ok`
- No unit-testable code here — this is workflow YAML only.
## ⚠️ Caveat: `production` environment protection rules
Adding `environment: production` means the job now runs in that environment. **If the `production` environment has deployment protection rules (required reviewers or a wait timer), the autoupdate job will PAUSE for approval on every push to `main`**, which would stall autoupdate entirely. Please confirm the `production` environment has **no blocking protection rules** for this use before/after merging.
Closes #23
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
The
autoupdateworkflow (.github/workflows/autoupdate.yml) authenticated its branch-update pushes with the defaultGITHUB_TOKEN. Pushes made withGITHUB_TOKENdo not re-trigger downstream workflow runs, so status checks were never re-run on the PR branches that autoupdate updated.This switches the token to the
STATUS_CHECKS_RETRIGGER_TOKENPAT (a personal access token with the right scopes) so autoupdate's pushes do re-trigger downstream status checks.Changes (only
.github/workflows/autoupdate.yml)environment: productionto theautoupdatejob so the environment-scoped secret is accessible.${{ secrets.STATUS_CHECKS_RETRIGGER_TOKEN }}instead of${{ secrets.GITHUB_TOKEN }}. The action still reads its token from theGITHUB_TOKENenv var — only the value changes.permissionsandPR_FILTERare unchanged.Validation
python -c "import yaml;yaml.safe_load(open('.github/workflows/autoupdate.yml'));print('ok')"→ok⚠️ Caveat:
productionenvironment protection rulesAdding
environment: productionmeans the job now runs in that environment. If theproductionenvironment has deployment protection rules (required reviewers or a wait timer), the autoupdate job will PAUSE for approval on every push tomain, which would stall autoupdate entirely. Please confirm theproductionenvironment has no blocking protection rules for this use before/after merging.Closes #23