LVTD-LLC Go CLI Release Automation
Treat release automation as a state transition with verifiable inputs, immutable artifacts, least privilege, and an explicit recovery path.
Core Workflow
- Define version, supported targets, artifact names, and release authority.
- Validate release configuration without publishing.
- Build final artifacts exactly once from a clean tagged commit and generate checksums.
- Publish through pinned, least-privilege CI with protected environments.
- Update package-manager metadata from the published artifacts.
- Install and smoke-test representative artifacts.
- Record partial state and recover without silently replacing released bytes.
Read Next
| Task | Load |
|---|---|
| Design and validate the pipeline | guidelines.md, workflows/validate-release-config.md |
| Publish a tagged release | workflows/publish-tagged-release.md |
| Publish Homebrew metadata | workflows/publish-homebrew-package.md |
| Recover a failed release | workflows/recover-failed-release.md |
| Review security and reproducibility | references/release-automation/rules.md |
| Review examples | references/release-automation/examples.md |
Guardrails
- Never release from an unreviewed or dirty source state.
- Do not grant write tokens to pull-request jobs or untrusted code.
- Pin CI actions and use current, supported GoReleaser configuration.
- Do not treat build tags as authorization controls.
- Do not overwrite published artifacts under the same version.
- Do not accept locally rebuilt bytes as recovery evidence.
Source Notes
Guidance is transformed and paraphrased from Marian Montagnino, Building Modern CLI Applications in Go (Packt, 2023), Chapters 7 and 12-14, and Ricardo Gerardi, Powerful Command-Line Applications in Go (2021).
Verify current configuration against https://goreleaser.com/, https://docs.github.com/en/actions/reference/security/secure-use, and the target package manager. Current GoReleaser deprecations must be checked before use.