Release

Tazuna releases use the setup of tag push triggering goreleaser via GitHub Actions. You normally do not invoke goreleaser directly from your machine when cutting a release.

This page summarizes “what happens when a release is cut,” “where version strings come from,” and “how to verify the artifacts.”

Trigger and Output

• Workflow: .github/workflows/release.yaml
• Trigger: push: tags: ["*"] (any tag push)
• Publish target: GitHub Releases

The tag name is embedded as the version string as-is. We recommend following semantic versioning (vX.Y.Z) (see also Changelog auto-generation).

Outputs

Build targets in .goreleaser.yaml are as follows.

The archive name is tazuna_<Os>_<Arch>.tar.gz (with amd64 normalized to x86_64), and the release includes:

• Per-OS/arch .tar.gz (binary)
• checksums.txt (SHA256)
• Per-archive + source SBOMs (*.sbom.json, SPDX)
• checksums.txt.sigstore.json (cosign keyless signing bundle)

GitHub Actions’ actions/attest-build-provenance separately generates SLSA build provenance, and links it in a form verifiable with gh attestation verify.

Version String Embedding

main.go declares the following vars, which are injected with -X at release-build time.

var (
    version = "dev"
    commit  = "none"
    date    = "unknown"
)

In .goreleaser.yaml’s ldflags:

-X main.version={{.Version}} -X main.commit={{.Commit}} -X main.date={{.Date}}

The injected values flow through cmd.SetVersionInfo and appear in tazuna version.

For local builds via go install / make build and similar, nothing is injected, so version / commit / date remain dev / none / unknown.

Changelog

The changelog section of .goreleaser.yaml assembles the GitHub Releases description.

• Order: ascending commit (sort: asc)
• Exclusions: commits with ^docs: / ^test: prefixes
• Format: header ## Tazuna {{.Version}}, with a compare link to the previous release in the footer

PR title / commit message conventions follow CONTRIBUTING.md / the PR template. docs: / test: prefixes do not appear in release notes, so attaching them to PRs that do not change product behavior makes inventory easier.

Artifact Verification

Users of the release have roughly 3 verification options.

# 1. Verify checksum
sha256sum -c checksums.txt

# 2. Verify checksums.txt signature (cosign keyless)
cosign verify-blob \
  --bundle checksums.txt.sigstore.json \
  checksums.txt

# 3. SLSA provenance の検証
gh attestation verify <file> --repo pepabo/tazuna

The third is to confirm SLSA build provenance via the GitHub CLI. Usable right after release and from internal CI as well.

Practical Steps When Cutting

1. Verify main is stable (CI green).
2. Cut and push a tag in vX.Y.Z form.
3. Confirm the Release workflow runs and the release is published.
4. If needed, hand-curate the auto-generated changelog.

The documentation site is published by a separate workflow (docs.yaml), triggered by pushes to main. It is independent of release cutting.