[DaedalusG]

The v8.1.1335 promotion ran finalize twice, and the run the release worker watches lost the race:

Build	Commit	Started by	Promote finalize
#3093	4d8b729 "release: v8.1.1335" (internal config commit)	creating promote/release-v8.1.1335	passed at 07:14: tagged the promote branch head a018051, pushed release-v8.1.1335, promoted on the release registry
#3094	21ae663 image update	push	test failed (no config)
#3095	a018051 "promote-release: v8.1.1335"	push	failed 4×: fatal: tag 'v8.1.1335' already exists

Creating the promote branch from the internal branch builds the internal config commit, and --config-from-commit accepts its config, so that build runs the promote jobs too. Its finalize tags whatever the promote branch head is when it gets there. This time that was the right commit, only because the tests ahead of it took about 7 minutes. Build #3095 is the one the release worker monitors (sourcegraph/sourcegraph#17343), so the promote workflow failed and never closed the release PRs or opened the "Update main" PR. The release itself is fine: tag v8.1.1335 is on a018051 with public images, and the registry shows it as public. v8.0.0 had the same race (#2990 passed finalize, #2993 failed it), but nothing monitored the promote build then.

This PR changes two things:

• Promote jobs run only for the promote config commit. (promote) Release: test and finalize now also require build.message =~ /^promote-release:/. Both the release worker and release.yaml's manual flow write that message.
• git:tag is retry-safe. If vX already points at the promote branch head, it skips creating the tag and continues. If it points anywhere else, it fails. The release registry's promote endpoint already treats re-promoting as a no-op (200), so a retried finalize now succeeds end to end.

How this was tested

• Job conditions. I checked the old and new conditions against the real branch and commit message of each v8.1.1335 build:

  Build	Promote jobs before	after
  #3093 release: v8.1.1335	run	skip
  #3094 Update Helm chart images…	run	skip
  #3095 promote-release: v8.1.1335	run	run
  Update main: build v8.1.1335 #978 promote/…-update-main	skip	skip

  This PR's own Buildkite build validates that the pipeline, with its new conditionals, uploads.

• git:tag. I extracted the step from release.yaml, stubbed gh and buildkite-agent, and ran it in fresh clones against a scratch bare remote:

  • First finalize: exits 0; the tag and release-vX are created on the promote head.
  • Retried or duplicate finalize (tag already on the promote head): exits 0 with "already points at … not recreating it"; refs unchanged.
  • Tag on a different commit: exits 1 with "already exists at , not at promote/release-vX ()".
  • Control: main's step on the retry case exits 128 with fatal: tag 'v9.9.9' already exists, the v8.1.1335 failure.

Rollout

Buildkite reads pipeline.yaml and release.yaml from the commit it builds, so patch releases need this on their X.Y.x branch. It's labelled backport 8.1.x, which applies cleanly. 8.0.x predates the -update-main exclusion, so it would need a manual backport if it gets more patches.

The same change is open for the other deploy repos: sourcegraph/deploy-sourcegraph-k8s#497 (k8s failed v8.1.1335 the same way) and sourcegraph/deploy-sourcegraph-docker#1449 (Docker avoided it only because the extra build was cancelled).

The v8.1.1335 cleanup is done by hand: #976 and #977 are closed, and #978 is the "Update main" PR.

[github-actions]

Open the Diff Tour for this PR in Sourcegraph

[sourcegraph-release-bot]

The backport to 8.1.x failed at https://github.com/sourcegraph/deploy-sourcegraph-helm/actions/runs/40064001079:

Reviews may only be requested from collaborators. One or more of the teams you specified is not a collaborator of the sourcegraph/deploy-sourcegraph-helm repository.

To backport this PR manually, you can either:

Via the sg tool

Use the sg backport command to backport your commit to the release branch.

sg backport -r 8.1.x -p 979

Via your terminal

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.1.x 8.1.x
# Navigate to the new working tree
cd .worktrees/backport-8.1.x
# Create a new branch
git switch --create backport-979-to-8.1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 ebaf2a25ef3988adce900e488dbb6690c7049387
# Push it to GitHub
git push --set-upstream origin backport-979-to-8.1.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.1.x

If you encouter conflict, first resolve the conflict and stage all files, then run the commands below:

git cherry-pick --continue
# Push it to GitHub
git push --set-upstream origin backport-979-to-8.1.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.1.x

• Follow above instructions to backport the commit.
• Create a pull request where the base branch is 8.1.x and the compare/head branch is backport-979-to-8.1.x., click here to create the pull request.

Once the pull request has been created, please ensure the following:

• Make sure to tag @sourcegraph/release in the pull request description.

• kindly remove the release-blocker from this pull request.