Skip to content

0054. Deriving Cauda-N Suffix from Deployment Image Tag

  • Status: proposed (auto-drafted by adr-suggester)
  • Date: 2026-07-26
  • Deciders: lusoris
  • Related: PR #3137

Context

The PR introduces a change to derive the Cauda-N suffix for CI image tags from the deployment image tag in templates/deployment.yaml. This ensures that CI image tags align with the deployed lineage, preventing mislabeling and ensuring consistency across deployment and CI pipelines.

Decision

The decision to derive the Cauda-N suffix from the deployment image tag represents a significant architectural change in how image tags are managed across CI and deployment pipelines, warranting an ADR.

Alternatives considered

  • Keep the hardcoded -cauda1/-cauda3 suffixes in the workflow: rejected — this is exactly what went stale (the lineage advanced to cauda9 while CI still emitted cauda1/cauda3), the failure this ADR exists to prevent.
  • A single manually-bumped caudaRev variable in the workflow: rejected — a second place to forget; the deployment pin is already the source of truth for what actually runs.
  • Derive from Chart appVersion only: insufficient — appVersion carries the paperclipai version, not the cauda-N overlay revision; the suffix lives only on the deployment image tag.

Consequences

  • CI image tags always match the deployed lineage; a bare lineage-advance re-pin republishes on the correct line with no workflow edit.
  • The workflow fails closed if the deployment pin lacks a cauda[0-9]+ suffix or disagrees with Chart appVersion — surfacing drift instead of silently mislabeling.
  • Any templates/deployment.yaml change now triggers a ghcr republish (harmless: the deployment pulls by Harbor digest); noted so it is not mistaken for a bug.

References

  • PR #3137 — fix(paperclip): derive CI image cauda-N suffix from the deployment pin