CI/CD Pipeline¶

The Kamerplanter CI/CD pipeline runs entirely on GitHub Actions. It covers automated quality checks for backend and frontend, building and publishing container images, and automated Helm chart publication. A release is started by a maintainer by hand; everything after that runs automatically in the correct order.

Prerequisites¶

• Write access to the GitHub repository (nolte/kamerplanter)
• No manual secret configuration required — all workflows use the automatically available GITHUB_TOKEN
• Container images are pushed to the GitHub Container Registry (GHCR) under ghcr.io/nolte/

Branch Strategy¶

feature/* ──► develop ──► (Release Tag v*) ──► main

Workflow Overview¶

Backend CI (backend.yml)¶

The backend CI workflow runs on every push to develop and on pull requests whenever files under src/backend/ are changed.

What is checked¶

1. Ruff lint — checks Python code for style and quality issues (ruff check .)
2. Ruff format — ensures the code is correctly formatted (ruff format --check .)
3. Unit tests — runs all tests under tests/unit/ with pytest

jobs:
  lint-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v5
        with:
          python-version: '3.14'
          allow-prereleases: true

      - name: Install uv
        uses: astral-sh/setup-uv@<sha>
        with:
          # Reads the uv version from [tool.uv].required-version. No workflow
          # spells out a uv version of its own.
          version-file: src/backend/pyproject.toml
          enable-cache: true
          cache-dependency-glob: src/backend/uv.lock

      - name: Install dependencies
        run: |
          uv sync --locked --extra dev
          echo "$PWD/.venv/bin" >> "$GITHUB_PATH"

      - name: Ruff lint
        run: ruff check .

      - name: Ruff format check
        run: ruff format --check .

      - name: Unit tests
        run: pytest tests/unit/ -v --tb=short

cd src/backend
ruff check .
ruff format --check .
pytest tests/unit/ -v --tb=short

Installing dependencies¶

Backend dependencies are installed from uv.lock, the hash-bearing lock resolved from pyproject.toml (internal reference: dependency requirement NFR-009). The [dev] extra includes pytest, ruff, and other development tools:

uv sync --locked --extra dev

Renovate health (renovate-health.yml)¶

Renovate reports its own failures only in the Dependency Dashboard (issue #12) — not as a red run, not as a missing pull request. A manager that finds nothing any more looks exactly like "there is nothing to update".

That is what happened between 2026-08-02 and 2026-09-10: Renovate's pip-compile manager extracted nothing for six weeks, the backend locks aged untouched, and every lane stayed green. The only signal was a ⚠️ WARN: pip-compile error line in the dashboard.

So this workflow reads the body of #12 daily and compares:

• Repository problems — every WARN/ERROR line under ## Repository problems is a finding and is quoted verbatim.

• The manager inventory — pep621 must extract from all five locked PEP 621 trees (backend + four service images), pip-compile must not appear at all, and no second manager (poetry, pip_requirements, pip-compile) may read a file inside any of those five trees.

  Why the rule is not \"poetry must not appear\"

  Measured with task renovate:dry-run (Renovate 44.94.1, 2026-09-16): enabled: false disables a manager's dependencies, not its extraction. poetry keeps reading the two lock-less libraries under src/libs/. A rule of the form "poetry must not appear" would have alerted on a correct repository every day.

  • The lock beside each package file — the dashboard lists no lock files, so this one fact is read from the checkout. The report says so explicitly.

On a finding the run opens or updates a single deduplicated issue (label renovate-health) instead of merely going red — a red scheduled run is invisible after a week of red scheduled runs. Conversely, when the run cannot decide (issue unreachable, empty body, unparseable dashboard) the run goes red and no issue is opened — an undetermined check must not read as a clean one (NFR-018 §2).

The expectation itself lives in scripts/ci/check_renovate_dashboard.py (EXPECTED_PEP621_FILES, KNOWN_LOCKLESS_PEP621_FILES); a new Python tree is added there rather than the rule being quietly widened.

task renovate:dry-run — prove the configuration before merging¶

renovate.json5 is the one configuration file in this repository that nothing verifies before a merge: a rule that matches nothing, an accidentally disabled manager, a typo in managerFilePatterns — all parse cleanly and are only discovered on the next Renovate run, hours later and on develop. That is exactly how the pip-compile manager went silent for six weeks.

task renovate:dry-run                      # manager inventory + proposed updates
LOG_LEVEL=debug task renovate:dry-run      # plus every extracted file individually

The command runs the pinned renovate/renovate CLI in Docker with --platform=local --dry-run=full against this working tree — including uncommitted changes, which is the point. src/backend/.venv, src/frontend/node_modules and node_modules are hidden by masking the mount, not by overriding ignorePaths: an override would prove a different configuration than the one production runs.

GITHUB_TOKEN is passed through when set; without it the datasource lookups run anonymously and hit the rate limit quickly — the manager inventory is still correct, the proposed updates are not.

Measured 2026-09-16 (Renovate 44.94.1) against this state:

That is the measurement renovate-health.yml holds the dashboard inventory against.

Frontend CI (frontend.yml)¶

The frontend CI workflow runs on every push to develop and on pull requests whenever files under src/frontend/ are changed.

What is checked¶

1. TypeScript check — strict type check without output (tsc --noEmit)
2. ESLint — quality check of the TypeScript/React code
3. Vitest — all unit and component tests
4. Vite build — ensures the production build compiles without errors

jobs:
  lint-test-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: 22    # (1)!
          cache: npm
          cache-dependency-path: src/frontend/package-lock.json

      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm run lint
      - run: npm run test
      - run: npm run build

1. Only the lint-test-build job uses Node 22. The bundle-budget and lighthouse jobs in the same workflow run on Node 24 — matching the frontend Dockerfile, which builds with node:24-alpine (see Frontend image below).

cd src/frontend
npx tsc --noEmit
npm run lint
npm run test
npm run build

Build artifact¶

On a push to develop (not on PRs), the finished dist/ directory is uploaded as a GitHub Actions artifact and retained for 7 days. This allows quick inspection of the build output without local compilation.

Performance budgets & CI gates (bundle-budget, lighthouse)¶

Besides lint-test-build, the same workflow runs two standalone jobs that watch frontend load performance (internal reference: UI-NFR-003). Neither touches the required static check — a violation surfaces visibly without blocking automerge.

bundle-budget — hard gate. The job builds the frontend, then runs npm run bundle:check (script scripts/check-bundle-budget.mjs) to check the initial JavaScript and CSS bundle plus the dedicated /dashboard route chunk against the budgets in bundle-budget.json:

Exceeding a budget fails the job; the bundle analyzer report (treemap via rollup-plugin-visualizer) is uploaded as the bundle-stats artifact. This budget is achievable thanks to a manualChunks vendor strategy in vite.config.ts: React, MUI core, Redux Toolkit, and react-i18next are eagerly grouped into stable, long-lived vendor chunks, while heavy route-scoped libraries (recharts, @mui/x-*, react-grid-layout) stay lazy.

cd src/frontend
npm run build
npm run bundle:check

lighthouse — report-only. The job runs npm run lhci (Lighthouse CI, mobile emulation with throttled 4G network) against the built dist/ folder and checks the Core Web Vitals thresholds from UI-NFR-003 (First Contentful Paint < 1.5 s, Largest Contentful Paint < 2.5 s, Time to Interactive < 3.5 s, Cumulative Layout Shift < 0.1, Total Blocking Time < 200 ms) plus the performance and accessibility scores (≥ 0.9). All assertions in lighthouserc.json are configured at warn level — the job does not block the build but surfaces regressions in the report. The full report is uploaded as the lighthouse-report artifact.

Container Build and Publication (docker-publish.yml)¶

This workflow builds and publishes all container images and the Helm chart. It is triggered by:

• Push to develop (when backend, frontend, or Helm files are changed)
• Push of a v* tag (release) — all components are built regardless of path changes
• Manually via workflow_dispatch

Path-based filtering¶

To avoid rebuilding all images on every change, a changes job first determines which components are affected:

src/backend/**  →  build-backend
src/frontend/** →  build-frontend
helm/**         →  publish-helm-charts

On a v* tag or manual trigger, the filtering is skipped — all components are always built.

Backend image¶

The backend image is based on python:3.14-slim and uses a multi-stage Dockerfile with a shared base stage plus separate dev and prod targets (docker build . without --target builds prod by default, since it is the last stage). The dev stage runs as root for Skaffold hot-reload; the prod stage runs as a non-root user (UID 1000):

FROM python:3.14-slim AS base
WORKDIR /app
COPY --from=ghcr.io/astral-sh/uv:0.12.12 /uv /bin/uv
ENV UV_PYTHON=/usr/local/bin/python3 UV_PYTHON_DOWNLOADS=never UV_PROJECT_ENVIRONMENT=/opt/venv PATH="/opt/venv/bin:$PATH"
COPY pyproject.toml uv.lock ./

FROM base AS prod
RUN uv sync --locked --no-install-project
COPY . .
RUN groupadd -g 1000 app && useradd -u 1000 -g 1000 -d /app -s /usr/sbin/nologin app \
    && chown -R 1000:1000 /app
USER 1000
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

The image is pushed to ghcr.io/nolte/kamerplanter-backend. Dependencies come exclusively from the hash-bearing uv.lock (internal reference: NFR-009): uv sync --locked refuses a lock that no longer satisfies pyproject.toml and verifies every artifact against its hash — the dependencies live in their own cacheable layer under /opt/venv, and the application is imported from /app.

Frontend image¶

The frontend image also uses a multi-stage Dockerfile: first the React app is built with Node.js 24, then the static files are copied into a slim, unprivileged nginx image (does not run as root, compatible with runAsNonRoot):

FROM node:24-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginxinc/nginx-unprivileged:1.31-alpine AS prod
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 8080

The image is pushed to ghcr.io/nolte/kamerplanter-frontend. The internal port is 8080 (unprivileged nginx can't bind to port 80), mapped to the public port 8080 in Docker Compose, and to port 80 on the service in the Helm chart.

Image tags¶

Docker metadata is automatically generated via docker/metadata-action:

What secures each artifact¶

Every artifact class this project ships needs a named stage that secures it — otherwise a gap only becomes visible once it is exploited. The matrix below answers the question "what exactly does what guarantee?" and is maintained alongside pipeline changes.

Known gaps — deliberately open, not overlooked:

• The three release assets carry no provenance. GitHub-hosted release files have no verification path equivalent to the registry attestation.
• JavaScript dependencies have no dedicated policy stage yet; Trivy covers them only at CRITICAL severity.

Verifying provenance¶

Images and the chart carry platform-generated, signed build provenance (actions/attest-build-provenance). Verify before deploying:

gh attestation verify \
  oci://ghcr.io/nolte/kamerplanter-backend:1.2.0 \
  --repo nolte/kamerplanter

What it says and what it does not: provenance establishes origin — which commit, which workflow run, which pinned inputs. It is not a statement that an artifact is secure. Security findings remain the concern of the supply-chain stages.

Helm chart¶

The Helm chart for Kamerplanter lives under helm/kamerplanter/ and is pushed as an OCI artifact:

oci://ghcr.io/nolte/charts/kamerplanter

On a release tag, version and appVersion in Chart.yaml are automatically set to the release version before the chart is packaged. On any other ref that rewrite does not apply — whatever version the tree carries is what gets packaged, and develop has its own channel for that (see Two channels). At the same time scripts/ci/pin_chart_image_digests.sh pins every Kamerplanter image in values.yaml to <version>@sha256:<digest> — addressed by YAML path rather than by text-replacing the literal tag: latest. The same run then re-reads the file and aborts the release if any Kamerplanter image survived the substitution.

The digest is resolved from the registry rather than handed over from the build jobs. That also proves <image>:<version> exists at all — which is why publish-helm-charts has been ordered behind the image builds via needs: since #987. And it is the difference between "immutable" and "immutable by convention": a version tag can be re-pushed, a digest cannot.

Two channels: develop and release¶

The same OCI address carries two kinds of tag, and they mean different things:

Two things the table does not say, and that are easy to read wrongly:

• Only the dev identifier is enforced on the -dev value, not the number in front of it. 0.2.1-dev names the intended next release, but it is not a promise: once v0.2.1 ships, 0.2.1-dev sorts below the release, and no schedule bumps the value. Nor does it need to — the collision stays impossible for any -dev number, which is exactly why the check demands nothing stronger.
• The example tag in the release row is 0.1.0, not 0.2.0. 0.1.0 still carries its release timestamp in the manifest (created 2026-08-06 at 13:38:04 UTC, 15 seconds after v0.1.0 was published), whereas 0.2.0 carries that of a develop build. 0.2.0 is therefore the one release tag the "Lifetime" column does not hold for — the incident below, unrepaired and hence not an example of the rule.

The two channels are disjoint, and that is enforced at both ends — as a check, not as a convention:

• scripts/check_chart_develop_version.py runs as a hook in the required static lane and rejects any chart version in the tree whose first pre-release identifier is not exactly dev. The develop tree therefore cannot carry a version a release would ever publish.
• scripts/ci/determine_chart_version.sh rejects the converse: a release tag carrying the dev pre-release identifier, before anything is packaged or pushed. v0.3.0-dev is not a valid release tag. v0.3.0-rc1 and v0.3.0-beta.1 stay legal — they cannot collide with the develop channel.

# Pull the chart directly — always a published version, never a -dev one
helm pull oci://ghcr.io/nolte/charts/kamerplanter --version 1.2.0

Layer caching¶

All image builds use the GitHub Actions cache (type=gha) for Docker layers. This significantly speeds up subsequent builds when only a few layers change.

Skaffold Verify (skaffold-verify.yml)¶

This workflow runs on pull requests to develop when skaffold.yaml, Helm files, or Dockerfiles are changed. It ensures the local development environment remains functional.

What is checked¶

1. helm dependency build — downloads chart dependencies (bjw-s common chart, valkey)
2. helm lint — checks the Helm chart for syntax errors using dev values
3. helm template — renders all Kubernetes manifests and validates the templating logic
4. skaffold diagnose — validates the Skaffold configuration
5. skaffold render — generates rendered manifests and uploads them as an artifact

Release Process¶

A release is the step that turns a state on develop into a delivered version. It does not start on its own: a human triggers it, and everything after that is automatic.

Step 1: Prepare release draft (automatic)¶

The release-drafter workflow automatically updates a release draft on every push to develop with the changes since the last tag. It also proposes the next version number.

Step 2: Publish the release (manual — the one hands-on step)¶

A maintainer starts release-publish.yml by hand: Actions → Release Publish → Run workflow, with the tag of the open draft. Sensibly with dry_run: true first — that validates without flipping the draft.

# Equivalent via the CLI
gh workflow run release-publish.yml -f tag=v1.2.0 -f dry_run=true
gh workflow run release-publish.yml -f tag=v1.2.0

Publishing is the moment the Git tag comes into existence in the first place — a draft has none.

Step 3: What hangs off the published release (automatic)¶

The resulting v* tag triggers docker-publish.yml: all images and the Helm chart are built with the release version number, and scripts/ci/pin_chart_image_digests.sh pins every Kamerplanter image in the chart values to <version>@sha256:<digest>.

In parallel, the "release published" event starts two more workflows:

release-cd-deliver-docs.yml — deploys the MkDocs documentation to GitHub Pages via a reusable workflow from nolte/gh-plumbing.

release-cd-refresh-master.yml — updates the main branch to the state of the new release tag. main therefore always points to the last published stable state.

Step 4: Release assets (automatic)¶

The update-release-assets job in the docker-publish workflow attaches the following files to the release:

• docker-compose-1.2.0.yml — versioned Docker Compose file for self-hosting
• .env.example-1.2.0 — environment variable template
• Container image references and Helm pull command in the release notes

Release flow summary¶

sequenceDiagram
    participant Dev as Maintainer
    participant GH as GitHub
    participant GHCR as ghcr.io

    Note over GH: release-drafter keeps a draft<br/>continuously up to date
    Dev->>GH: run release-publish.yml (tag=v1.2.0) — manual
    GH->>GH: draft = published, Git tag v1.2.0 comes into existence
    GH->>GH: docker-publish.yml starts (trigger: v* tag)
    GH->>GHCR: push backend image :1.2.0
    GH->>GHCR: push frontend image :1.2.0
    GH->>GHCR: push Helm chart :1.2.0 (images pinned by digest)
    GH->>GH: attach release assets
    GH->>GH: deploy MkDocs docs
    GH->>GH: update main branch

Deployment and rollback¶

A cluster does not learn about a new version because a tag was moved. The published chart references every Kamerplanter image by an immutable digest that the release job writes in at packaging time:

image:
  repository: ghcr.io/nolte/kamerplanter-backend
  tag: 0.2.1@sha256:af9bec…    # (1)!
  pullPolicy: IfNotPresent      # (2)!

1. What matters is the part after the @. The digest is content-addressed and cannot move. The version in front of it is not a moving reference but a label — nothing resolves it. In the repository this field reads tag: latest: scripts/ci/pin_chart_image_digests.sh rewrites every Kamerplanter reference to <version>@sha256:<digest> at release time, and scripts/check_chart_image_digests.py proves in the same job that none escaped. The develop tree with latest is therefore explicitly not a deploy channel (see Two channels).
2. Deliberately stays IfNotPresent. A digest is content-addressed: an image already on the node is the requested one, so a re-pull could only confirm it. Always would make every pod start depend on GHCR being reachable and would gain nothing. With a moving latest the same value would be a trap — one more reason the tree is not rolled out.

How a new version reaches production¶

The production instance rolls out release versions only. That is an operating decision, not merely the accidental current state: the ArgoCD Application anchors the chart at a published chart version, not at a branch.

graph TD
    A[1. Merge to develop] --> B[2. docker-publish<br/>images to GHCR, tag latest]
    B -.pre-stage, does not reach production.-> C
    C[3. Maintainer publishes a release<br/>MANUAL] --> D[4. docker-publish pins<br/>chart images to version + digest]
    D --> E[5. Raise targetRevision in the GitOps repo<br/>to the new chart version — MANUAL]
    E --> F[6. ArgoCD syncs, pods roll]

Spelled out, that is six hops, each owned by a different actor:

1. Merge to develop — the commit that changes the code. A human.
2. docker-publish.yml builds the images and pushes them to GHCR, where :latest moves on. This is the pre-stage: it makes the build available but does not reach production — nothing in helm/kamerplanter/values.yaml on develop changes because of it. (Until 2026-09-10 Renovate wrote the new digests to develop here via a pull request; that fed no deployment and the PR was rebased by every publish without ever merging.)
3. A maintainer cuts a release — by hand, via release-publish.yml. The first manual hop. If it does not happen, nothing from steps 1 and 2 is delivered, no matter how long ago it was.
4. docker-publish.yml runs on the resulting v* tag and, via scripts/ci/pin_chart_image_digests.sh, pins every Kamerplanter image in the chart values to <version>@sha256:<digest>.
5. targetRevision in the GitOps repository is raised to the new chart version — also by hand, in nolte/k8s-home-lab, that is outside this repository. The second manual hop, and the only one no workflow in this repository can even see.
6. ArgoCD syncs the new state. The pods roll because the pod spec changed — not because someone triggered a restart.

The deploy itself is therefore a commit — in the GitOps repository — not an operation on the cluster. That the digests in the published chart are present and well-formed is enforced by scripts/check_chart_image_digests.py right after pinning in the release job; which version the instance actually runs is answered only by the instance itself (see Checks along the delivery chain).

Rollback¶

A rollback is a commit in the GitOps repository: set targetRevision back to a previous chart version.

- path: .
  repoURL: oci://ghcr.io/nolte/charts/kamerplanter
  targetRevision: 0.1.0   # instead of 0.2.1

ArgoCD pulls the older chart version — together with the digests that version pins — and the pods roll back. Verify the result in the running pod, not in the values file and not from a controller status:

kubectl get pod -n kamerplanter -l app.kubernetes.io/name=backend \
  -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.status.containerStatuses[0].imageID}{"\n"}{end}'

imageID names the digest the kubelet actually started. It has to match the one the chart values pin under the tag you rolled back to.

Production: the Application lives in the GitOps repository¶

The ArgoCD Application for the Talos cluster is not in this repository but in k8s-home-lab (src/applications/kamerplanter/deploy/argocd/application.yaml). It pulls the published chart from the registry:

- path: .                                              # (1)!
  repoURL: oci://ghcr.io/nolte/charts/kamerplanter
  targetRevision: 0.2.1                                # (2)!

1. The OCI artifact, not a directory in the Git tree. path: . is the artifact's own root.
2. A published chart version, not a branch — the release version without the leading v, so release v0.2.1 is chart 0.2.1. Only a published release can stand here, and nobody raises this value automatically.

What a release is for¶

A release is at once the delivery vehicle for this instance and the packaging for everyone else. What hangs off it:

Invariant: no image.tag in the overlay¶

An overlay configuring this instance carries no per-controller image.tag overrides. That is not a recommendation but the condition under which the digest pin holds at all.

The division of labour is: targetRevision picks the chart version, the chart picks the bytes. An image.tag in the overlay breaks the second half.

The consequence has been measured twice, not feared:

• In the first incident (tracked internally as ticket 1024) a rollout restart silently kept an old image; the inference-service served a state without the /pest/* routes for weeks.
• In the second (tracked internally as ticket 1210) the overlay anchored targetRevision: v0.1.0 with six per-controller image.tag overrides set to 0.1.0 — images from release v0.1.0, published 2026-08-06. The fix from #1163 merged into develop on 2026-08-14 and could not be part of that release. It was fixed on 2026-08-16 at 15:33 UTC by 3e53606c8, which switched targetRevision to develop and removed every override.

Both times it looked healthy from the outside: registry, chart and controller status all agreed. Only the running container did not. That is why the proof is always the look into the pod, never into the values file.

The invariant is written out next to the digests it protects — in helm/kamerplanter/values.yaml and in the overlay itself. Change it there, not here.

Checks along the delivery chain¶

The six hops fail independently of one another. A check over one transition therefore says nothing about the others:

What release-lag.yml does — and what it does not¶

The job compares the state of develop against the newest published release daily at 09:00 UTC. A draft explicitly does not count; it is even named in the alert, because a draft is precisely what creates the impression that something has been delivered. Reporting goes into a single, deduplicated issue labelled release-lag. The measurement report release-lag-report.json exists only in the runner's workspace and is not uploaded as an artifact — it gates the issue step: if it is missing, the measurement was undetermined, the run goes red, and no issue is opened.

RELEASE_LAG_THRESHOLD_DAYS is a cadence policy, not an unexplained grace window. The expectation for this repository is: a merged fix should be delivered within 3 days at the latest — published and with the production instance's targetRevision raised, the two manual hops from How a new version reaches production. The setting enforces only the first half of that cadence: it reports once the oldest un-released commit has exceeded the 3 days, i.e. once publishing is late. It has no way to check the second half — see the "A release does not prove the cluster took it" box below, which covers exactly that gap.

It is a scheduled job and not a pull-request gate because the lag grows with no commit at all: it increases with every hour nobody publishes, and it shrinks the moment somebody does. Neither of those events is a push.

Pulling GHCR packages¶

All images are publicly readable. For local testing:

docker pull ghcr.io/nolte/kamerplanter-backend:latest
docker pull ghcr.io/nolte/kamerplanter-backend:1.2.0

docker pull ghcr.io/nolte/kamerplanter-frontend:latest
docker pull ghcr.io/nolte/kamerplanter-frontend:1.2.0

helm pull oci://ghcr.io/nolte/charts/kamerplanter --version 1.2.0
helm install kamerplanter oci://ghcr.io/nolte/charts/kamerplanter --version 1.2.0

Frequently Asked Questions¶

curl -s https://your-instance.example.com/api/health

{
  "status": "healthy",
  "version": "1.0.0",
  "mode": "light",
  "supported_majors": [1],
  "build_revision": "37cbc06fcf0c7d69c07f7abbd3d485cb241070da"
}

kubectl get pod -n kamerplanter -l app.kubernetes.io/name=backend \
  -o jsonpath='{range .items[*]}{.status.containerStatuses[0].imageID}{"\n"}{end}'

# 0. Fill in what you want to check.
IMAGE="nolte/kamerplanter-backend"
TAG="0.0.23"
FIX_COMMIT="<fix-commit>"

# 1. Get an anonymous pull token (the package is public, no login needed)
TOKEN=$(curl -s "https://ghcr.io/token?scope=repository:${IMAGE}:pull&service=ghcr.io" \
  | jq -r '.token')

# 2. Fetch the tag's manifest and read the OCI revision annotation.
#    The index media type must stay in the Accept header: these tags are
#    multi-arch, the annotation sits on the index, and asking for the image
#    manifest alone returns a body in which it is null.
REV=$(curl -s -H "Authorization: Bearer ${TOKEN}" \
     -H "Accept: application/vnd.oci.image.index.v1+json,application/vnd.oci.image.manifest.v1+json" \
     "https://ghcr.io/v2/${IMAGE}/manifests/${TAG}" \
  | jq -r '.annotations."org.opencontainers.image.revision"')
echo "${REV}"
# b40b3ccd8393a612876bdf8c48ad0144f81e32c3

# 3a. Check whether the fix commit is contained in that revision.
#     Guard both commits first: `--is-ancestor` exits 128 when *either*
#     one is unknown locally (shallow clone, missing tag, stale fetch) —
#     folding that into the `||` branch reports a confident "not
#     contained" for a question that was never actually answered.
if ! git cat-file -e "${REV}^{commit}" 2>/dev/null \
   || ! git cat-file -e "${FIX_COMMIT}^{commit}" 2>/dev/null; then
  echo "revision or fix commit not known locally — fetch before concluding anything"
elif git merge-base --is-ancestor "${FIX_COMMIT}" "${REV}"; then
  echo "contained"
else
  echo "not contained"
fi

# 3b. Alternative: list every tag carrying the fix commit
git tag --contains "${FIX_COMMIT}"

See also¶

• Kubernetes Deployment
• Helm Chart Configuration
• Local Development Setup