fix(ci): set release token inline so project GITLAB_TOKEN can't shadow it

Jay McCurerequested to merge
fix-release-token-shadowing into main

What

The first scheduled tag-release run failed with a 401 creating the tag (job 14883755197):

New release tag: v1.103.0
glab: HTTP 401
{"error":"invalid_token","error_description":"Token is expired..."}

Root cause

GITLAB_TOKEN_RELEASE is not expired. The problem is variable shadowing: the project has a separate, project-level GITLAB_TOKEN CI/CD variable (an old/expired token). The tag-release job set the token via its variables: block:

variables:
  GITLAB_TOKEN: $GITLAB_TOKEN_RELEASE

…but project/group CI/CD variables outrank job-level variables: in GitLab's precedence. So at runtime the project GITLAB_TOKEN won, glab authenticated with that expired token, and got the 401. The script logic itself worked end-to-end (it correctly computed v1.103.0); only the auth was wrong, and no tag was created.

Fix

Assign the release token inline in the script step instead of via variables:. An inline assignment expands $GITLAB_TOKEN_RELEASE directly and isn't subject to the shadowing:

script:
  - GITLAB_TOKEN="$GITLAB_TOKEN_RELEASE" scripts/release/create-release-tag.sh

This matches the existing pattern in this file — notify-issues-on-release (GITLAB_TOKEN="$GITLAB_TOKEN_RELEASE_NOTES" ./scripts/...) and the goreleaser release job (docker run -e GITLAB_TOKEN=$GITLAB_TOKEN_RELEASE) both set it inline for exactly this reason.

After merge

Re-run the weekly schedule (or wait for Sunday) — it will recompute v1.103.0, see it doesn't exist, and create it.

🤖 Generated with Claude Code

Merge request reports