[imanimanyara]

Summary

dbpantry stops publishing container images, and its release moves onto the org's two triggers. The owner decided on 2026-11-13 that a release ships on the GitHub release only, and answered "Yes, stop images" for this repo.

git push origin vX.Y.Z                                               # releases vX.Y.Z
gh workflow run release.yml --repo simtabi/dbpantry -f tag=vX.Y.Z     # the same, for a tag already pushed

What it published before:

• Engine images, one per engine per supported major, to ghcr.io/simtabi/dbpantry-<engine>.
• The cli image, to ghcr.io/simtabi/dbpantry-cli.
• Per-architecture tags plus a multi-architecture manifest.
• An SBOM and build provenance pushed to the registry for each image, and provenance for each manifest.
• A GitHub release: CHANGELOG notes plus contributors, dbpantry-X.Y.Z.tar.gz, its .sha256, and provenance for the tarball.
• No binaries.

What it publishes now: only the GitHub release, unchanged.

The ghcr.io images are frozen. No new tag is pushed and nothing is deleted from ghcr.io. Measured 2026-11-13, no dbpantry package exists under simtabi on ghcr.io, and no GitHub release exists yet (the one release run, v0.1.0, failed). So no consumer can have pulled one.

Why dbpantry keeps its own jobs instead of calling simtabi/.github's shared go-release.yml: that workflow runs GoReleaser and publishes binaries, and dbpantry releases no binaries. Porting would add a release channel it does not have. It would also lose the scan and verify gates, the tag-on-main check, the MongoDB refusal and the contributors list. This is the same library-style exception as simtabi/cloudkit#4.

Removed

• Job publish (one run per image per architecture), with every step in it:
  • Build (a rebuild of the image, for pushing)
  • Install trivy and syft
  • Scan the image about to be pushed (the second scan)
  • Push: docker login ghcr.io, tagging <tag>-<arch>, docker push, reading the digest, and the syft SBOM
  • Attach the SBOM: actions/attest with push-to-registry: true
  • Attach the build provenance: actions/attest with push-to-registry: true
  • Its permissions packages: write, id-token, attestations and artifact-metadata
• Job manifest, with every step in it:
  • Create the multi-architecture manifest: docker login ghcr.io and docker buildx imagetools create
  • Attach the build provenance to the manifest: push-to-registry: true
  • Its permissions, including packages: write
• The confirm input and the Refuse without confirm=release-go step. A new first step refuses anything but a vX.Y.Z[-pre] tag that exists on GitHub.

There were no image-only secrets: logins used github.token.

Kept. The Dockerfiles stay: make build uses them, not only the publish job. Also kept:

• the scan gate: every image is built and Trivy-scanned on amd64 and arm64, on native runners
• the verify gate: make verify on both architectures
• the strict vX.Y.Z check, the tag-on-main check, the CHANGELOG section check and the MongoDB refusal
• the GitHub release job, with its tarball, checksum, provenance and contributors

The release job now needs: [prepare, scan, verify] instead of manifest.

Changed

• Triggers: push on v[0-9]+.[0-9]+.[0-9]+ tags, and workflow_dispatch with a required tag input. Concurrency is per tag and never cancelled. No -* pre-release filter: dbpantry refuses pre-releases, so an rc push would only start a run that fails.
• Tag handling: the tag is inputs.tag || github.ref_name, and every checkout is refs/tags/<tag>. The tag-on-main check now tests HEAD instead of GITHUB_SHA, because on a dispatch GITHUB_SHA is the branch head, not the tag's commit.
• Guard: src/internal/release has TestReleaseRunsOnAVersionTagOrOnRequest and TestReleasePolicyRejectsAWrongRelease. They assert the two triggers, version-only tag filters, a required tag input, a first step that refuses before any checkout, tag-only checkouts and every job needing the gate. They fail on any image publish: docker/login-action, build-push-action, bake-action or metadata-action; docker login or docker push; buildx --push; imagetools create; crane/oras push; skopeo copy; push-to-registry: true; packages: write. A local scripts/build plus trivy image must still pass.
• Docs: docs/guides/release.md, README.md, SECURITY.md, CHANGELOG.md [Unreleased], and a new design.md entry, D-77. The image tag scheme is kept, marked frozen.

Consumers to decide on separately (not changed here): scripts/backends/kubernetes.sh and the Helm chart (global.imageRegistry: ghcr.io/simtabi) still pull from the frozen registry. A Kubernetes user now has to push their own build or point global.imageRegistry at their own registry. The CHANGELOG says so.

Verification

• make go-ci (gofmt, vet, tests): green. make go-lint: 0 issues. make verify-structure: 72 checks well-formed. make lint: shellcheck clean on 148 files. actionlint 1.7.12: clean on all three workflows. scripts/release-notes Unreleased: renders. The docker-dependent make verify runs in CI's release gates, not here.
• The guard was proven red against the real release.yml with go test -count=1, one defect at a time, and the file restored (confirmed with cmp). Each of these failed: branches: [main]; a schedule; packages: write; a docker/login-action step; a docker/build-push-action step; a docker push ghcr.io/... step; the release job's checkout without ref. The old main workflow fails four ways: no tag push, no tag input, no tag resolution, and packages: write. Twenty-four synthetic cases in the companion test fail too, and the local build-and-scan control passes.

Also fixed: check 48 on the current amd64 runner

The first CI run's verify (amd64) failed on 48-runtime-detection with ln: failed to create symbolic link '/tmp/mdb-rt-tools.*/grub-ntldr-img': Already exists. verify (arm64) passed, and the last weekly run on main (2026-11-09) passed.

• Cause: the check builds a tool directory from /usr/bin and /bin, skipping a name already linked with [[ -e ]]. That test follows symlinks, so a dangling /usr/bin/grub-ntldr-img on the current ubuntu-latest amd64 image reads as absent. Since /bin is /usr/bin there, the second pass links it again, and ln stops the check.
• Fix: commit 697d64a tests -L as well, so every other name behaves as before.
• Reproduced: with a dangling link in a doubled directory, the old test fails and the new one passes. shellcheck is clean, and the check passes locally.

This is unrelated to the release change, but it blocked green.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.