Skip to content

charts: Keep chart READMEs unchanged across releases - #963

Draft
DaedalusG wants to merge 1 commit into
mainfrom
wg/plat-876-release-invariant-helm-docs
Draft

DaedalusG wants to merge 1 commit into
mainfrom
wg/plat-876-release-invariant-helm-docs

Conversation

@DaedalusG

@DaedalusG DaedalusG commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Every release rewrites the image digests and registry in values.yaml and the chart version in Chart.yaml, and all three show up in the generated READMEs. That forced the release worker to regenerate the READMEs with its own copy of helm-docs. When that copy drifted from scripts/helm-docs.sh, internal/release-v8.1.0 failed ":book: Verify helm-docs is up-to-date" and had to be fixed by hand. The regeneration also doesn't reach customers. The publish Action packages the chart from the first push to promote/release-*, before the docs commit lands, so the published sourcegraph-8.0.0.tgz README lists the internal registry as the default.

This PR makes the READMEs independent of everything a release changes, so the release worker can drop its helm-docs step entirely (sourcegraph/sourcegraph#17056):

  • Every pinned image defaultTag gets # @default -- `<appVersion>@sha256:<digest>`, pinned by each release, and sourcegraph.image.repository gets # @default -- Sourcegraph's public Docker Hub registry, in the four charts the release updates. The two executor images also get the # -- description helm-docs needs before it honors @default. The registry annotation deliberately avoids the literal registry string, because the release replaces that string everywhere in values.yaml, comments included.
  • The migrator README uses a <chart-version> placeholder instead of {{ template "chart.version" . }}.
  • A new CI step fails if any chart README renders a pinned digest or index.docker.io/sourcegraph. A new image added without an annotation then fails on its own PR rather than on the next release branch. It is a separate step so it doesn't conflict with CI: Make helm-docs.sh portable #954, which rewrites the existing helm-docs step.

The tradeoff is that the values tables no longer list the exact digests; values.yaml and helm show values still do.

I simulated both release phases with the release worker's own values.yaml rewrite (dev/images.UpdateHelmManifestContent) plus the Chart.yaml bump, then ran ./scripts/helm-docs.sh. On main that produces 68 changed README lines after the internal phase and 60 after promote. On this branch it produces none for either phase.

Merge this, and backport it to every X.Y.x branch that still gets patch releases (at least 8.0.x and 8.1.x), before the release worker change deploys. Patch releases branch from X.Y.x, and a branch without these annotations would fail the helm-docs check once the worker stops regenerating READMEs.

Part of PLAT-876.

Every release rewrote image digests, the registry, and the chart version in
the chart READMEs, so the release worker had to regenerate them with a copy
of helm-docs. When that copy drifted from scripts/helm-docs.sh, the release
branch failed the helm-docs check (v8.1.0, PLAT-876).

Annotate the release-managed values in values.yaml with `# @default --`, and
use a `<chart-version>` placeholder in the migrator README. The generated
READMEs no longer depend on anything the release changes, so the release
worker can stop regenerating them. A new CI step fails if a README renders a
pinned digest or the public registry again.

Amp-Thread-ID: https://ampcode.com/threads/T-01a13c8e-c52e-7584-ab27-1a7fb05bc3b7
@github-actions

Copy link
Copy Markdown

This branch has not been deployed

No deployments
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.

1 participant