Release Workflow

Release Workflow

Trove uses GitHub Actions, release-please, GoReleaser, and GHCR.

This page describes the intended flow for maintainers.

Normal flow

branch -> PR -> CI -> merge to main
          |
          v
release-please updates release PR
          |
          v
merge release PR when ready
          |
          v
v* tag exists or is created by release automation
          |
          v
GoReleaser publishes GitHub Release and GHCR images

CI

The CI workflow runs on pushes and PRs.

It checks:

• gofmt
• go vet
• go test
• release build

The protected branch expects the CI job name configured in GitHub branch protection. If that job name changes, branch protection needs updating too.

Commit prefixes

Release versioning follows conventional-style prefixes:

Prefix	Effect
fix:	patch material
feat:	minor material
feat!: or BREAKING CHANGE:	major material
docs:, ci:, chore:	no version bump by themselves

Release-please

Release-please maintains the release PR.

That PR usually updates:

• CHANGELOG.md
• .release-please-manifest.json

Do not treat the release PR as a feature branch. It is release paperwork.

GoReleaser

GoReleaser runs from a pushed v* tag.

It publishes:

• GitHub Release notes/assets
• checksums
• binaries
• GHCR images and multi-arch manifests

Verify releases

After a release:

gh release view vX.Y.Z
gh release list

Check container images:

docker pull ghcr.io/techdox/trove-server:X.Y.Z
docker pull ghcr.io/techdox/trove-agent-docker:X.Y.Z
docker pull ghcr.io/techdox/trove-agent-k8s:X.Y.Z
docker pull ghcr.io/techdox/trove-agent-proxmox:X.Y.Z

GHCR visibility gotcha

New GHCR packages can default private even when the repository is public.

If a new image is added and users cannot pull it, check the package visibility in GitHub's UI.

Latest release gotcha

GitHub's latest marker is based on release state, not always what humans expect.

After unusual release edits, check:

gh release list

If needed:

gh release edit vX.Y.Z --latest

Emergency manual tag

If automation fails but the code is ready and the release version is known:

git tag -a vX.Y.Z -m "release vX.Y.Z"
git push origin vX.Y.Z

Use this as a fallback, not the normal habit.