Wikantik Release and Deploy Process

The path from main-branch code to running production on docker1. This is the release runbook; generic Docker operation for any installation is covered by WikantikOnDocker.

The pipeline

  1. Gate locally. bin/run-tests.sh --parallel 4 (unit phase + parallel IT phase) is the canonical pre-commit/pre-release gate. This matters doubly here because the release CI does not run tests.
  2. Cut the release. bin/cut-release.sh bumps the version, commits, and tags. Known quirk: with no TTY it exits 1 at the push confirmation — the commits and tag already exist; finish with git push origin main vX.Y.Z. Post-release, main is bumped to the next -SNAPSHOT.
  3. CI builds the image. The tag push triggers release.yml on GitHub-hosted runners (the self-hosted runner host has had no registered runners since ~May 2026 — jobs targeting it queue forever). It builds and pushes ghcr.io/jakefearsd/wikantik:vX.Y.Z in roughly 22 minutes. It skips the test suite by design.
  4. Deploy. bin/deploy-release.sh pulls the released image to production; equivalently bin/remote.sh deploy --pull vX.Y.Z. The deploy path health-polls and auto-rolls-back on a failed health check; manual rollback is bin/remote.sh rollback (re-promotes the :rollback tag).
  5. Verify. bin/remote.sh status (health + container ps + disk + pages size); watch the wikantik dashboards on docker2.

Versioning vocabulary

In this project, "minor release" colloquially means a patch bump (2.3.x → 2.3.x+1). Never bump the SemVer minor without an explicit decision — this has caused an unwind before.

What a deploy does NOT do

A deploy replaces the application container only. The database, page store, and search indexes persist — corpus changes travel by a different path entirely: Wikantik Content vs Code Deployment.

See Also