ci(facts): use the existing org-level REGISTRY_TOKEN
All checks were successful
PR checks / checks (pull_request) Successful in 9m11s
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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user