Update Click-Dog¶

Choose the update workflow that matches the deployment. A standard systemd installation has a config-aware update path; Ansible, Kubernetes, and Docker keep their own deployment state and should be updated through their respective tools.

Standard systemd installation¶

The safest current update path for a guided systemd install is install.sh update. You do not need to keep the script after installation; download the current copy when an update is needed:

curl -fsSL https://github.com/coltconsulting/click-dog/releases/latest/download/install.sh -o install.sh &&
sudo bash install.sh update

Use Verify releases first when your policy requires the root-run script itself to be authenticated.

install.sh update is systemd-only and refuses to continue when /etc/systemd/system/click-dog.service is absent. It:

downloads and verifies the selected release, or accepts -b with a pre-verified binary
stages and smoke-tests the new binary
rejects a downgrade
validates the existing /etc/click-dog/click-dog.yaml with the staged binary
copies the outgoing binary to /usr/local/bin/click-dog.prev
swaps the binary, restarts the service, and requires systemd to report it active

The update does not rewrite the config or credentials. If staged validation fails, the old binary stays in place and the running service is not interrupted.

Pin a version¶

Resolve the stable release once, then use that value consistently across a rollout:

LATEST_URL="$(curl -fsSL -o /dev/null -w '%{url_effective}' \
  https://github.com/coltconsulting/click-dog/releases/latest)" || exit 1
VERSION="${LATEST_URL##*/v}"

sudo bash install.sh update -v "$VERSION"

--no-merge remains accepted for backward compatibility but is a no-op. Update-time config merging has been removed.

`self-update`: the lighter alternative¶

The installed binary can also update itself:

sudo click-dog self-update --check
sudo click-dog self-update

self-update verifies the same release signature/checksum chain, smoke-tests the new binary, atomically preserves the outgoing binary as .prev, and restarts click-dog when systemd reports it running.

Unlike install.sh update, it does not validate the existing configuration with the staged binary before the swap or require the restarted systemd service to become active. Use it for a direct binary installation or when you have already validated configuration compatibility. Use the installer update for the stronger standard-systemd preflight.

Configuration across updates¶

New config keys have runtime defaults, so an existing YAML remains usable when keys are added. To materialize newly recommended settings, render a fresh profile and compare it with your checked-in configuration:

click-dog init --profile production -o /tmp/click-dog-new.yaml
sudo diff -u /etc/click-dog/click-dog.yaml /tmp/click-dog-new.yaml

Apply chosen changes deliberately, validate, and restart. Do not rerun the guided installer merely to obtain new defaults: its reinstall choice rerenders the whole configuration from your answers.

Guided installer over an existing installation¶

Running the guided installer again detects /usr/local/bin/click-dog and offers three choices:

[u] Update — replace binary, keep existing config and credentials
[r] Reinstall — overwrite config and service; keep existing credentials
[q] Quit

Choose Update for a version change. It uses the same safe path as install.sh update. Choose Reinstall only when you intentionally want to rerender the service and config from current answers and defaults.

Detection is based on /usr/local/bin/click-dog. A binary relocated manually after installation is not recognized as an existing guided install.

Roll back a systemd update¶

Both update paths keep one prior binary at /usr/local/bin/click-dog.prev. Stop the service before copying over its active executable:

sudo systemctl stop click-dog
sudo cp /usr/local/bin/click-dog.prev /usr/local/bin/click-dog
sudo systemctl start click-dog
click-dog version

Alternatively, stage and rename the rollback binary before restarting:

sudo cp /usr/local/bin/click-dog.prev /usr/local/bin/click-dog.rollback
sudo mv /usr/local/bin/click-dog.rollback /usr/local/bin/click-dog
sudo systemctl restart click-dog

Only one prior generation is retained. A later update overwrites .prev with the binary it replaces. Configuration is not rolled back; if you added keys that the older binary does not recognize, revert those changes separately.

Public prereleases¶

The stable paths resolve GitHub's latest GA release. Add --prerelease to self-update or the installer when intentionally selecting a public beta:

Where no stable release exists yet, install.sh takes the newest beta and says so; self-update does not, and needs --prerelease explicitly. The kubernetes and docker generators never switch channel on their own.

sudo click-dog self-update --check --prerelease
sudo click-dog self-update --prerelease

When install.sh --prerelease is used without -v, it scans the 20 most recent public GitHub Releases and selects the first prerelease in that window. Pin an older public prerelease explicitly with -v. Private alpha releases are not discoverable through the public installer or self-update.

Ansible fleets¶

Run the same playbook with a pinned click_dog_version. The playbook preserves the outgoing binary as .prev, validates configuration through its restart handler, and can roll back with the rollback tag. Follow Update an Ansible fleet.

Kubernetes¶

Refresh the generated image reference and reapply the manifests. Follow Update Kubernetes.

Docker¶

Refresh the generated image reference, then recreate the Compose service. Follow Update Docker.