dunn.dev/pipeline 4.3.1
Patch: reference-check migrates off the magic-name GITLAB_TOKEN group
variable to ESTATE_READ_API_TOKEN, with a fallback during the dual-variable
migration window. No new inputs, no removed/renamed inputs.
Fixed
- reference-check: GITLAB_TOKEN (provisioned in 4.2.0) is a magic name glab
prioritizes over CI_JOB_TOKEN autologin for every glab call across every
job in the dunn.dev group -- not just this recipe's own reads. A
read_api-only token squatting on that name silently broke
dunn.dev/cairn/pipeline's create-release job (403 insufficient_scope:
glab picked up the read-only group token instead of the write-capable
CI_JOB_TOKEN). Migrated the recipe to read ESTATE_READ_API_TOKEN instead,
falling back to GITLAB_TOKEN during the migration window, scoped inside
the recipe's own subshell only -- nothing exported process-wide.
- reference-check: no longer exports an empty GITLAB_TOKEN. A naive
GITLAB_TOKEN="${ESTATE_READ_API_TOKEN:-${GITLAB_TOKEN:-}}" would export
an empty GITLAB_TOKEN when neither variable is set, and an empty
magic-name variable shadows CI_JOB_TOKEN autologin exactly like a
wrong-scoped one -- the identical failure mode this release exists to
fix, reintroduced one layer down. Now unsets GITLAB_TOKEN when the
resolved value is empty, so autologin sees a genuinely clean
environment.
The GITLAB_TOKEN fallback stays in place only for the dual-variable
migration window and should be dropped once the group GITLAB_TOKEN
variable is deleted.
Tag convention unchanged since 2.0.0: bare semver, no v-prefix. See
CHANGELOG.md for the full entry.