Tag-driven release workflow: pushing a tag produces the artefacts, and somebody downloads one

Status

To do

Component

release

Priority

High — the only repeatable way to run SAPE-3 twice

Blocked by

SAPE-1

Blocks

—

Description

Add a workflow to packages/sapedb that fires on a version tag, builds the four targets and the container image from SAPE-3, stamps the tag into each binary, computes checksums, and publishes the lot. The pattern does not have to be invented: it already runs for real in this workspace and can be adapted rather than designed.

Why now

A release built by hand is a release that is correct once. The version stamp, the four targets and the checksums all depend on somebody remembering the same sequence, and the first time anyone finds out it was remembered wrong is the release after. This is also the "stranger cannot install it" category by a second route: artefacts that only appear when a human is available do not appear.

Measured 2026-09-20. packages/sapedb has no .github directory at all. Three sibling repositories in the same workspace do: packages/ecosy-next/.github/workflows/publish.yml, packages/ecosy-anchor/.github/workflows/publish.yml, and packages/ecosy-sapedb/.github/workflows/ with both publish.yml and test.yml. That last one is sapedb's own TypeScript client: the client already has a release workflow and the server it talks to does not.

Acceptance criteria

1. Pushing a test tag runs the workflow to completion with no manual step in the middle.
2. The run produces every artefact SAPE-3 lists, attached to the release for that tag, with the checksum file.
3. An artefact is downloaded onto a clean machine and executed there. It starts, and sapedb version prints the tag that was pushed. An artefact nobody has downloaded is an artefact that does not exist, so this criterion is not met by a green workflow run.
4. The download in criterion 3 is fetched from the published URL, by a machine that has never had this repository checked out.
5. Run twice, on two different tags. A release path that has run once has only proved it can be configured, not that it works.

Out of scope

• Release workflows for the three clients. Each client repository tags on its own line — see SAPE-2 — and the TypeScript one already has one.
• Publishing to npm, crates.io or any package registry from this workflow. The server is a binary and an image.
• Generating release notes from commits. The CHANGELOG is written by hand on purpose.
• Running the clients' test suites against the tagged daemon. That belongs to the release-day sequence, not to this workflow.