RunicGateway/runicgateway.com
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ci(facts): use the existing org-level REGISTRY_TOKEN
All checks were successful
PR checks / checks (pull_request) Successful in 9m11s
Details

Browse Source 
checkFacts needs to read link, servuo-plugins, website and installer, and
the automatic per-run token is scoped to this repo alone. Rather than mint
a new secret, the workflow uses REGISTRY_TOKEN, which already exists at the
org level with the right permissions.

The secret is named for the registry and the script reads GITEA_TOKEN; the
mapping stays in the workflow so the script keeps asking for what it
actually wants -- a Gitea token -- rather than this org's secret name.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
claude
2026-08-19 20:46:18 -05:00
parent d4ab453361
commit b287728c19
3 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -56,7 +56,9 @@ on protocol 3, because every checkout in the workspace sat on a feature branch w
never been fetched.
It needs a token — anonymous raw fetches fail on this Gitea instance, and a check that silently skips
itself is worse than no check at all.
itself is worse than no check at all. It must be able to read the other repositories in the
organisation, not just this one. CI already has this: the workflow maps the org-level
`REGISTRY_TOKEN` secret into `GITEA_TOKEN` for that step.
**`checkTokens.mjs`** fails the build if a colour literal appears anywhere in `src/` outside
`src/styles/tokens.css`. §7 promises that recolouring the site is a file copy and a container