Skip to content

feat(ci): Publish distroless image under the default tag - #8301

Draft
oioki wants to merge 1 commit into
masterfrom
feat/distroless-default-image-tag
Draft

feat(ci): Publish distroless image under the default tag#8301
oioki wants to merge 1 commit into
masterfrom
feat/distroless-default-image-tag

Conversation

@oioki

@oioki oioki commented Aug 13, 2026

Copy link
Copy Markdown
Member

Point the unsuffixed ghcr tags at the distroless build, so every consumer of the default image — self-hosted, nightly, and craft releases — gets the distroless variant. The previous default image is still published under a -distroful suffix as a fallback.

Distroless has run in production (all SaaS and single-tenant regions, services and migration jobs) for over a month without issues. This extends it to everyone else.

Tag Before After
<sha>, nightly application distroless
<sha>-distroful, nightly-distroful application (previous default)
<sha>-distroless, -debug variants unchanged

Why assemble is the only lever

The unsuffixed <sha> tag is the choke point: it feeds :nightly, the self-hosted-end-to-end job, and craft, which retags <sha> into the versioned release and :latest. Retargeting assemble switches everyone at once, with no .craft.yml change — craft's status contexts keep their job names, and assemble now transitively gates on the distroless builds so a release can't be cut before that manifest exists.

Note this is a workflow change, not a Dockerfile one; both build stages already exist and are unchanged. arm64 is covered — the distroless multiplatform build already produces both architectures.

Self-hosted compatibility (checked against getsentry/self-hosted @ de88f0b)

Distroless has no shell, so I audited self-hosted for shell dependencies. It's clean:

  • Healthchecks are exec-form ["CMD", "python3", ...] using only stdlib urllib — no curl/wget/shell. The shared file-healthcheck anchor is inline python3, explicitly written to work across images.
  • All snuba command: values (rust-consumer, replacer, subscriptions-scheduler-executor, accepted-outcomes-consumer) are plain subcommands, and each resolves under the distroless Python entrypoint's snuba/cli/<name>.py lookup. No shell form, no entrypoint: overrides.
  • No docker exec … bash against snuba anywhere in the repo; the custom-CA setup uses docker create/docker cp, not in-container shell.

Two residual notes: users who manually docker exec -it snuba-… bash to debug will need the -debug (busybox) variant instead, which is worth a release note; and it's worth confirming the DHI base ships /etc/ssl/certs, since the custom-CA flow copies that baseline out of the image.

Follow-ups, deliberately not here

  • Google AR untouched. gocd pins -distroless explicitly, so production is already distroless and the plain AR tag is vestigial. Renaming it needs a grep of getsentry/terraform first.
  • -distroful covers <sha> and nightly, but craft only publishes the plain tag as versioned releases, so a user pinned to a version would have to pin by sha. A craft target for -distroful would close that if we want a true escape hatch.
  • Once this settles, the application stage and its build jobs can be dropped.

Point the unsuffixed ghcr tags at the distroless build so every consumer
of the default image — self-hosted, nightly, and craft releases — gets
the distroless variant. The previous default image is still published,
now under the -distroful suffix, so it stays available as a fallback.

The unsuffixed <sha> tag is the single choke point downstream: it feeds
:nightly, the self-hosted end-to-end job, and craft, which retags <sha>
into the versioned release and :latest. Retargeting the assemble job
therefore switches everyone at once, with no .craft.yml change needed.

Wire the assemble and self-hosted-end-to-end jobs to the distroless
builds so the self-hosted e2e suite exercises the distroless image
against the real compose stack before craft can cut a release from it.

Co-Authored-By: Claude <noreply@anthropic.com>
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