Skip to content

(internal) release_minor: build v6.3.0 - #1201

Closed
Chickensoupwithrice wants to merge 1 commit into
mainfrom
internal/release-v6.3.0
Closed

Chickensoupwithrice wants to merge 1 commit into
mainfrom
internal/release-v6.3.0

Conversation

@Chickensoupwithrice

Copy link
Copy Markdown
Contributor

Test plan: automated release PR, CI will perform additional checks

{"version":"v6.3.0","inputs":"server=6.3.0","type":"minor"}
@sourcegraph-buildkite

Copy link
Copy Markdown
  • 🟢 Internal release is ready for promotion!
  • ⚠️ Do not close/merge that pull request or delete the associated branch if you intend to promote it.

@sourcegraph-buildkite

Copy link
Copy Markdown

DaedalusG added a commit that referenced this pull request Oct 24, 2026
…1449)

In v8.1.1335, the k8s and Helm repos both failed their promotion the
same way: creating the promote branch builds its first commit, the
internal config commit "release: vX". `--config-from-commit` accepts
that config, so the build runs the promote test and finalize jobs too.
Its finalize tags the promote branch head, and the build the release
worker monitors, for the "promote-release: vX" commit, then fails
finalize with `fatal: tag 'vX' already exists`. The promote workflow
fails and skips closing the release PRs and opening "Update main". See
sourcegraph/deploy-sourcegraph-k8s builds #1197/#1201 and
sourcegraph/deploy-sourcegraph-helm builds #3093/#3095.

This repo has the same pipeline conditions and `git:tag` step. It got
through v8.1.1335 only because the build of the internal config commit
([#16700](https://buildkite.com/sourcegraph/deploy-sourcegraph-docker/builds/16700))
was cancelled 10 seconds after it started, when newer commits arrived.
That depends on a pipeline setting, not on anything in this repo.

This is the same change as sourcegraph/deploy-sourcegraph-helm#979 and
sourcegraph/deploy-sourcegraph-k8s#497:

- **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 this repo's
`release.yaml` 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 this
repo's real v8.1.1335 promote-branch commits. Before, every commit ran
the promote jobs. After, only `63f7963` "promote-release: v8.1.1335"
runs them; `8f0974d` "release: v8.1.1335" and `6845a34` (image update)
skip them. This PR's Buildkite build validates that the pipeline, with
its new conditionals, uploads.
- **`git:tag`.** I extracted the step from this repo's `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 on the
promote head.
- **Retry or duplicate:** exits 0 with "already points at … not
recreating it".
- **Tag on another commit:** exits 1 with a message naming both commits.
- **Control:** `main`'s step on the retry case exits 128 with `fatal:
tag 'v9.9.9' already exists`.

## 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`; both files are identical on `8.1.x`, so the
backport applies cleanly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants