Releases

Daevix has no stable release yet. Three pre-release tags exist (v0.0.1-rc1 through v0.0.1-rc3), and the first stable tag is pending.

How a release is cut

A release is a git tag that starts with v. Pushing such a tag triggers the release workflow in .tangled/workflows/build.yaml. That workflow also runs on manual dispatch. Nothing else in CI ships an artifact: the lint workflow only lints, and the release workflow proves a property. It publishes nothing.

The canonical distributable is what a user gets from go install:

go install go.daevix.com/daevix/cmd/dvx@<tag>

There is no separate release pipeline that produces a different binary. The release workflow verifies the bytes of that exact command.

The reproducible build workflow

On a v* tag push, the release workflow installs the tagged module twice, into two independent module caches and install roots, and compares the two SHA-256 digests. A mismatch fails the run. The workflow pins each input that could change the bytes:

• The exact Go toolchain, parsed from the toolchain line in go.mod (currently go1.27.1). GOTOOLCHAIN=auto would let a newer runner Go change the bytes.
• CGO_ENABLED=0, GOOS=linux, GOARCH=amd64, so the host C toolchain and target never leak in.
• -trimpath, so the build path does not leak in. Two install roots show that the build does not depend on the path.

The release workflow prints the digest and the binary’s self-reported version, then discards the binaries. The binary self-reports the tag with no linker flags: internal/version reads Go’s build info. A plain go build of a working tree reports (devel) and can never match the tagged install.

You can verify a published digest yourself with the same toolchain and target:

export GOTOOLCHAIN=go1.27.1 CGO_ENABLED=0 GOOS=linux GOARCH=amd64
GOBIN="$PWD/out" go install -trimpath \
  go.daevix.com/daevix/cmd/dvx@<tag>
sha256sum out/dvx

Compare the output against the digest in the release notes. The full explanation, including why each source of non-determinism is pinned the way it is, is in docs/reproducible-builds.md in the repository.

Container images and deploys

There is no automated deploy. Container images are built locally with make image, which passes the git describe version, commit, and date into the image as build arguments. Loading that image into a development cluster is separate (make kind-load). No CI workflow pushes images or deploys to any environment.

Where the docs site version comes from

The version in the site footer is never hard-coded. The layout reads site.Params.version, which Hugo receives as the environment variable HUGO_PARAMS_VERSION. The Makefile target gen-site-scripts sets that variable from git describe --tags --abbrev=0 and regenerates the two hero Script SVG partials with the same tag as their seed and message. The target check-site-scripts verifies that the committed SVGs still decode to the tag-sourced message. A local hugo build with no HUGO_PARAMS_VERSION set falls back to the branch label in the footer.