ci: give the workflow tokens a value that exists

[razbroc]

Question	Answer
Bug fix	✔
New feature	✖
Breaking change	✖
Deprecations	✖
Documentation	✖
Tests added	✖
Chore	✔

Two workflows have been failing on every run. Same cause, one line each.

PR Author Auto Assign   ##[error]Input required and not supplied: repo-token
release-please          ##[error]release-please failed: Input required and not supplied: token

secrets.GH_PAT is not configured on this repo (gh secret list is empty), so both inputs resolved to an empty string and each action refused to start. Both now prefer GH_PAT and fall back to github.token, which is always populated. Each job already grants the permissions its action needs — pull-requests: write for the assigner, contents: write + pull-requests: write for release-please — so neither depends on a secret existing. If the org sets GH_PAT later it takes precedence with no further change.

⚠️ Why the two earlier attempts had no effect

908f19a and a88de87 both fixed auto-author-assign.yml, and neither changed anything, because both landed on a feature branch.

The evidence is on the four PRs opened this morning. repo-token per ref at the time they ran:

ref	value
master	${{ secrets.GH_PAT }}
feat/ticket-polling-worker	${{ secrets.GH_PAT || secrets.GITHUB_TOKEN }}
feat/claim-and-release	${{ github.token }}
feat/implement-and-verify	${{ github.token }}

Run 33045474256 is PR #7, whose base is feat/claim-and-release — a ref that already carried github.token. It still failed with the empty-input error. PR #8, based on feat/implement-and-verify, also carried github.token and also failed.

So pull_request_target is not resolving this workflow from the base branch; the copy on the default branch is the one that executes. That also means a88de87's conclusion — that the secrets.GH_PAT || secrets.GITHUB_TOKEN fallback "still resolved to an empty input" — was measuring a file that never ran. secrets.GITHUB_TOKEN was most likely fine all along.

Consequence for review: this is the only place a fix to that workflow is visible, and it has to merge to master directly rather than riding the MAPCO-11429 → 11431 → 11434… stack.

Expect a conflict when the stack merges

feat/ticket-polling-worker (#5) and feat/claim-and-release (#6) both carry their own edits to auto-author-assign.yml. Merging either into a master that has this change will conflict on that one line. Take this version — ${{ secrets.GH_PAT || github.token }} — and drop the branch's.

The release-please trade-off is real

Events created with GITHUB_TOKEN do not trigger workflows, so the release PR release-please opens will not run the pull_request checks. That is the reason a PAT is the usual advice for this action, and it is why the original file carried that comment. The release itself is unaffected.

The alternative is leaving every push to master red until someone provisions GH_PAT. A release PR with no CI on it seems the better failure, and it is documented in the file so whoever sets the secret knows what they are fixing. Say the word if you'd rather this workflow stayed failing until the PAT exists — happy to drop that half.

Refs: MAPCO-11429