Sign in

Search issue titles and bodies, change requests and comments. Private repositories you cannot read are not included.
vole
Clone

Read only, no credentials:

https://rodent.software/vole.git

Write over SSH with a registered key:

git clone ssh://git@rodent.software:2222/vole.git

A free and open-source forge that lives in your Git repo.

#206

P1: Rehearse and bootstrap the first public release

closed · opened by keenan 3d ago

keenan opened this 3d ago

Why

There are no tags on the repository, and the tag-driven release workflow (.vole/workflows/release.yaml) has never run end to end. The verify workflow builds and packages one architecture, but it does not exercise the v* trigger, the SBOM step, or release: true.

At the same time, docs/deploy/*.md and docs/packaging.md already fetch https://rodent.software/r/vole/releases/v0.2.0/artifacts/..., so the first public server cannot follow the deployment guide until a v0.2.0 release with those files exists. The first machine is also a bootstrap: the guides download the package from the instance being deployed, and that instance does not exist yet.

Scope

  • Rehearse in a throwaway repository on the instance: tag it, let the release workflow build and attach the packages, download and install the .deb on a test VM, then delete the repository. Do not attempt the real first release cold: once a file is attached to a release, the release is immutable.
  • Decide the version before tagging. cmd/vole/main.go and every deployment guide say 0.2.0; if the first release is a different number, update all of them in the same change and say so in the release note.
  • Record the bootstrap path for the first production server: run the release steps locally (vole workflow run release builds but does not publish), use a temporary package URL, or attach a locally built package by hand. The first instance must exist before its own release page can be used.
  • Make sure a runner is registered on the public instance before the real tag is pushed. The tag workflow attaches the artifacts from that runner.
  • Write the tag’s release notes, including the metadata tree (changes/<ulid>/change.md) and the route rename (#205).
  • After publishing, check that every URL in docs/deploy/*.md matches the attached file names and the version.

Checklist

  • Rehearse tag, release build, attach, download, and install on a throwaway repository and VM.
  • Decide and record the first version.
  • Bootstrap the first production machine.
  • Register a runner on the public instance.
  • Push the real tag with release notes.
  • Verify the package URLs and checksums in the deployment guides.
  • Link the release from the README or deployment guide.

Acceptance

  • The real release page carries the .deb, .rpm, plain binaries, SHA256SUMS, and the SBOM, and a clean machine installs from the documented URL.
  • A second machine can be created by following docs/deploy/ without a manual build step.
  • The rehearsal and bootstrap needed no secret in a workflow file or a log.

Related: #94 (signing), #205 (route rename).

Comments (0)

No comments yet.