Release process

Use this checklist before tagging a release. It is intentionally short and biased toward the checks that catch real release regressions.

v0.1.0 checklist

1. Clean verification

From the repo root:

go test -count=1 ./...
make build
make check
make docs-build
make release

What this should prove:

• unit and package tests pass from a cold test run
• the binary builds locally
• the example config still validates
• cross-compiled release artifacts are produced with the expected names

2. Docs verification

From the repo root:

make docs-build

What this should prove:

• the docs site still builds cleanly
• navigation/content changes did not break the static documentation surface

If Next reports that another build is already running, clear the stale generated lock from website/.next/lock and rerun the build.

3. CLI smoke checks

From the repo root:

./bin/deeplo version
./bin/deeplo --help
./bin/deeplo daemon --help
./bin/deeplo check --config examples/config/example.yml

Check manually:

• version prints the expected release version when built with VERSION=v0.1.0
• help text matches the documented command set and wording
• the example config still validates successfully

4. Release artifact sanity

Verify bin/ contains:

deeplo_linux_amd64
deeplo_linux_arm64
deeplo_darwin_amd64
deeplo_darwin_arm64

Optional quick checks:

• run file bin/deeplo_linux_amd64 to confirm it is a static ELF binary
• run one built binary locally to confirm it starts and prints help/version

5. Documentation sanity

Check these surfaces before tagging:

• README.md
• Installation guide
• Bootstrap config guide
• Triggers guide
• Configuration reference
• CLI reference
• State reference
• v0.1.0 release notes draft

Confirm:

• the native (systemd) and Docker install paths are both clearly documented
• advanced features such as git-managed config and CONFIG_WATCH are clearly secondary
• docs match current code and command output
• no stale names or removed config shapes remain

Useful repo-root grep:

rg -n "deeplod" README.md website/content/docs

No hits should remain outside of intentional legacy-migration context.

6. Optional runtime smoke test

If you have a disposable host or local test environment:

1. Start the daemon: deeplo daemon (or via systemd/Docker).
2. Run deeplo check --probe-hosts against a real config.
3. Confirm /healthz returns 200 ok.
4. If using webhooks, send one real or test GitHub delivery and confirm it reaches the daemon.

7. Tag and release

Build with the intended version:

make build VERSION=v0.1.0
make release VERSION=v0.1.0

Then:

1. Commit final docs/release-note changes.
2. Tag the release: git tag v0.1.0
3. Push the tag.
4. Publish release artifacts and release notes.

Notes

• deeplo version prints dev unless the binary is built with the VERSION=... make variable or equivalent linker flags.
• deeplo refresh is an observed runtime snapshot only. It should not be used as evidence that deployment history was rebuilt.
• Poll mode dispatches a branch-tip SHA once. A failed deploy of the same SHA is not retried automatically on the next poll cycle.