Pulse/docs/RELEASE.md

Pulse Release Checklist

Use this checklist when preparing and publishing a new Pulse release.

Pre-release

• Ensure VERSION is up to date and matches the tag you plan to cut (format 4.x.y)
• Confirm the Helm chart renders and installs locally:

  helm lint deploy/helm/pulse --strict
  helm template pulse deploy/helm/pulse \
    --set persistence.enabled=false \
    --set server.secretEnv.create=true \
    --set server.secretEnv.data.API_TOKENS=dummy-token
  

• (Optional) Run the Kind-based integration test locally:

  kind create cluster
  helm upgrade --install pulse ./deploy/helm/pulse \
    --namespace pulse \
    --create-namespace \
    --set persistence.enabled=false \
    --set server.secretEnv.create=true \
    --set server.secretEnv.data.API_TOKENS=dummy-token \
    --wait
  kubectl -n pulse get pods
  kind delete cluster
  

Publishing

1. Tag the release (git tag v4.x.y && git push origin v4.x.y) or draft a GitHub release.

2. Package the Helm chart locally so you can preview the artifact (the GitHub workflow performs the same command, but local packaging provides an explicit hand-off):

   ./scripts/package-helm-chart.sh 4.x.y
   # Optional: push to GHCR after authenticating
   # helm registry login ghcr.io
   # ./scripts/package-helm-chart.sh 4.x.y --push
   

   The script emits dist/pulse-4.x.y.tgz, and scripts/build-release.sh copies the tarball into release/ alongside the binary archives. Uploading can be handled manually with the --push flag or delegated to the automated workflow described below.

   scripts/build-release.sh automatically runs the same packaging step (unless you export SKIP_HELM_PACKAGE=1) so release archives and chart tarballs are produced together.

3. If you rely on automation, monitor the Publish Helm Chart workflow (triggered by the release) to ensure it finishes successfully. When running entirely locally, skip this step and verify the push command completed.

4. (Optional) Sign release/checksums.txt by exporting SIGNING_KEY_ID=<gpg-key-id> before running scripts/build-release.sh, or re-run the signing step manually:

   SIGNING_KEY_ID=<gpg-key-id> ./scripts/build-release.sh
   # or sign later
   gpg --detach-sign --armor --local-user <gpg-key-id> release/checksums.txt
   

   Publish both checksums.txt and checksums.txt.asc so users can verify artifacts:

   gpg --verify checksums.txt.asc checksums.txt
   

5. Update the release notes to include an upgrade/install snippet pointing at GHCR, for example:

   helm install pulse oci://ghcr.io/rcourtman/pulse-chart \
     --version 4.x.y \
     --namespace pulse \
     --create-namespace
   

6. Mention any chart-breaking changes (new values, migrations) in the release notes.

Post-release

• Verify helm show chart oci://ghcr.io/rcourtman/pulse-chart --version 4.x.y shows the expected metadata (version, appVersion, icon)
• Run helm install against a test cluster (Kind/k3s) using the published OCI artifact
• Announce the release with links to both the GitHub release and the Helm installation instructions (docs/KUBERNETES.md)
• Verify signatures: gpg --verify checksums.txt.asc checksums.txt