The autoupdate workflow (#20) uses the default GITHUB_TOKEN. Pushes made with GITHUB_TOKEN do not re-trigger downstream workflow runs, so when autoupdate refreshes a PR branch, CI/status checks do not re-run on the updated branch.
A PAT with the proper scopes is provisioned as the secret STATUS_CHECKS_RETRIGGER_TOKEN in the production GitHub Actions environment. Using it as the token for the autoupdate action makes autoupdate's branch-update pushes re-trigger status checks.
Scope
In .github/workflows/autoupdate.yml, add environment: production to the job so the environment secret is accessible.
Source the action token from secrets.STATUS_CHECKS_RETRIGGER_TOKEN (set the action's GITHUB_TOKEN env to it) instead of the default GITHUB_TOKEN.
Update the explanatory comment (autoupdate pushes now DO re-trigger checks).
Keep the action pinned by commit SHA.
Acceptance criteria
On a push to main, autoupdate updates open PR branches and the updated branch re-runs its status checks (CI, once #3 exists).
Caveat to verify
If the production environment has deployment protection rules (required reviewers / wait timer), a job referencing it will pause for approval on every push to main, which would stall autoupdate. Confirm the environment has no blocking protection rules for this use (or that pausing is acceptable).
## Context
The autoupdate workflow (#20) uses the default `GITHUB_TOKEN`. Pushes made with `GITHUB_TOKEN` do **not** re-trigger downstream workflow runs, so when autoupdate refreshes a PR branch, CI/status checks do not re-run on the updated branch.
A PAT with the proper scopes is provisioned as the secret **`STATUS_CHECKS_RETRIGGER_TOKEN`** in the **`production`** GitHub Actions environment. Using it as the token for the autoupdate action makes autoupdate's branch-update pushes re-trigger status checks.
## Scope
- [ ] In `.github/workflows/autoupdate.yml`, add `environment: production` to the job so the environment secret is accessible.
- [ ] Source the action token from `secrets.STATUS_CHECKS_RETRIGGER_TOKEN` (set the action's `GITHUB_TOKEN` env to it) instead of the default `GITHUB_TOKEN`.
- [ ] Update the explanatory comment (autoupdate pushes now DO re-trigger checks).
- [ ] Keep the action pinned by commit SHA.
## Acceptance criteria
- On a push to `main`, autoupdate updates open PR branches and the updated branch re-runs its status checks (CI, once #3 exists).
## Caveat to verify
If the `production` environment has deployment protection rules (required reviewers / wait timer), a job referencing it will pause for approval on every push to `main`, which would stall autoupdate. Confirm the environment has no blocking protection rules for this use (or that pausing is acceptable).
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.
Context
The autoupdate workflow (#20) uses the default
GITHUB_TOKEN. Pushes made withGITHUB_TOKENdo not re-trigger downstream workflow runs, so when autoupdate refreshes a PR branch, CI/status checks do not re-run on the updated branch.A PAT with the proper scopes is provisioned as the secret
STATUS_CHECKS_RETRIGGER_TOKENin theproductionGitHub Actions environment. Using it as the token for the autoupdate action makes autoupdate's branch-update pushes re-trigger status checks.Scope
.github/workflows/autoupdate.yml, addenvironment: productionto the job so the environment secret is accessible.secrets.STATUS_CHECKS_RETRIGGER_TOKEN(set the action'sGITHUB_TOKENenv to it) instead of the defaultGITHUB_TOKEN.Acceptance criteria
main, autoupdate updates open PR branches and the updated branch re-runs its status checks (CI, once #3 exists).Caveat to verify
If the
productionenvironment has deployment protection rules (required reviewers / wait timer), a job referencing it will pause for approval on every push tomain, which would stall autoupdate. Confirm the environment has no blocking protection rules for this use (or that pausing is acceptable).