ci: refuse release versions already tagged in canonical or security

John Masonrequested to merge
jmason-ci-guard-version-collisions into main

🤖 AI-authored change, reviewed by @johnmason.

What does this MR do and why?

Stops the weekly release automation from reusing a version number that a security release already took. That is what diverged canonical and security main this week and blocked the 19.4 tag (see !937 (merged) for the cleanup).

release_create_mr picks the next version from git describe and git-cliff --bumped-version, which only see tags reachable from main. A security release is tagged in the security repository first and stays private until it ships, so it is invisible here:

  • 2026-09-07: security had tagged v5.14.12 on 09-03. The weekly job saw v5.14.11 as latest and opened !929 (merged) for v5.14.12. Merged → two different v5.14.12 tags.
  • 2026-09-14: v5.14.13 existed off-lane (69d74f2a, cut from v5.14.7). The weekly job proposed it again in !936 (closed). Had it merged, version_tag would have hit "already exists, skipping" and exited green with VERSION on main naming a tag on another commit.

Changes

release_create_mr — after computing the next version, check repository/tags/v$NEXT in this project and in gitlab-org/security/gitlab-elasticsearch-indexer. Any hit fails the job with a message saying which repository has it and what to do. Fail closed: no MR is better than a duplicate version.

version_tag — the "tag already exists" branch now compares the tag's commit to $CI_COMMIT_SHA and fails when they differ, instead of skipping. Also gated to $CI_PROJECT_PATH == gitlab-org/gitlab-elasticsearch-indexer: the security project has no TAG_CREATOR_TOKEN, so every main push there has failed at this job since at least July (glab auth login: flag needs an argument: --token), and a bot tagging in security is exactly how the two repositories end up with the same version on different commits.

doc/process.md — documents both behaviours and the new variable.

⚠️ Action required before the next weekly run (Monday 2026-09-21 00:06 UTC)

The security check needs a SECURITY_REPO_READ_TOKEN CI/CD variable on this project (masked): a read_api token with at least Reporter access to gitlab-org/security/gitlab-elasticsearch-indexer. Without it the job fails with an explicit message and opens no MR — safe, but no release either.

GitLab returns 404 for a private project the token cannot see, which would read as "tag is free", so the job probes /projects/:id for a 200 before trusting a 404 on the tag.

Not in this MR (follow-ups)

  • Stale release MRs: the job opens a new MR every week even when one is open; lint:changelog-metadata then fails the old one. 14 orphaned release_* branches back to 2025-09.
  • TAG_CREATOR_TOKEN / INDEXER_RELEASE_TOKEN expiry with no warning (expired 2026-09-07, #203).
  • doc/process.md versioning section says patch tags live on stable branches; in practice every 5.14.x tag is on main.

Verification

  • YAML parses; both job scripts pass bash -n.
  • Tag JSON parsing tested against the live API: tags/v5.14.14 → 23563ebc79e62feb87fa65ca1d5d279dac3bca53.
  • Unauthenticated GET /projects/gitlab-org%2Fsecurity%2Fgitlab-elasticsearch-indexer → 404, confirming the access probe is necessary.
  • Not verified: an end-to-end scheduled run with the token in place. Suggest a manual pipeline with SCHEDULE_TYPE=weekly_release after the variable is added; the version check should report v5.14.15 is free in both the canonical and the security repository.

Merge request reports