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

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:
2026-08-19 20:46:18 -05:00
parent d4ab453361
commit b287728c19
3 changed files with 13 additions and 6 deletions

View File

@@ -44,11 +44,15 @@ jobs:
#
# This needs a token that can read the OTHER repositories in the org: link,
# servuo-plugins, website and installer. The automatic per-run token is scoped
# to this repository alone and will 404 on all four, so the job reads an
# org-level secret instead.
# to this repository alone and 404s on all four, so the job uses the org-level
# REGISTRY_TOKEN, which already exists and already carries the right scope.
#
# The secret is named for the registry; the script reads GITEA_TOKEN. Mapping it
# here rather than renaming either side keeps the script's interface honest — it
# wants a Gitea token, not this org's particular secret.
#
# It runs last, and it is the only step that touches the network, so a Gitea
# outage cannot mask a real failure in the build.
env:
GITEA_TOKEN: ${{ secrets.PLATFORM_READ_TOKEN }}
GITEA_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
run: npm run check:facts