blumeops/docs/how-to/zot/pin-container-versions.md
Erich Blume c86b5d7772
All checks were successful
Build Container / detect (push) Successful in 3s
Build Container / build-dagger (navidrome) (push) Successful in 22m26s
Native Dagger container builds + Navidrome v0.61.1 (#330)
## Summary
- Move Dagger module from `.dagger/` to repo root (`src/blumeops/`), rename `blumeops-ci` → `blumeops`
- Replace opaque `docker_build()` with native Dagger pipelines that surface full build errors per step
- Migrate navidrome as the first container (`containers/navidrome/container.py`)
- Upgrade navidrome from v0.60.3 to v0.61.1 (major artwork overhaul, SQLite FTS5 search, server-managed transcoding)
- Add `dagger call container-version` for CI version extraction without Dockerfile parsing
- All mise tasks (`container-list`, `container-version-check`, `container-build-and-release`) updated for hybrid mode
- Legacy `docker_build()` fallback preserved for all other containers

## Motivation
When navidrome v0.61.0 added a new Go build tag (`sqlite_fts5`), `docker_build()` showed only "exit code: 1". We had to run `docker build --progress=plain` manually to find `undefined: buildtags.SQLITE_FTS5`. Native Dagger pipelines show the full error inline.

## Container build dispatch needed
After merge, dispatch container build for navidrome:
```
mise run container-build-and-release navidrome --ref 470b4bd
```

## Deploy steps
1. Wait for container build to complete
2. Back up navidrome-data PVC (non-reversible DB migrations)
3. `argocd app set navidrome --revision main && argocd app sync navidrome`
4. Verify at https://dj.ops.eblu.me

## Future
Remaining containers migrate incrementally in follow-up PRs using the same pattern.

Reviewed-on: #330
2026-04-11 17:11:56 -07:00

2.2 KiB

title modified tags
Pin Container Versions 2026-04-11
how-to
containers
ci
zot

Pin Container Versions

Ensure every container has an explicit, parseable version declaration so that add-container-version-sync-check has something to validate against.

Context

Discovered during analysis of adopt-commit-based-container-tags: containers needed a uniform, parseable version declaration for the sync check. Most containers already had version ARGs (miniflux, navidrome, ntfy, etc.), but with inconsistent naming (NAVIDROME_VERSION, MINIFLUX_VERSION, etc.), and several containers (devpi, cv, quartz, nettest) had none.

What Was Done

Every container Dockerfile declares ARG CONTAINER_APP_VERSION=X.Y.Z as its first ARG, providing a uniform parsing target. Containers that use the version in build commands chain it to a semantic ARG:

ARG CONTAINER_APP_VERSION=v0.60.3
ARG NAVIDROME_VERSION=${CONTAINER_APP_VERSION}

Note: Containers migrated to native Dagger builds use VERSION = "X.Y.Z" in container.py instead. See containers/navidrome/container.py for the pattern. New containers should use container.py rather than Dockerfiles.

Specific changes:

  • devpi: Pinned devpi-server==6.19.1 and devpi-web==5.0.1
  • cv: CONTAINER_APP_VERSION=1.0.3 (matches latest Forgejo package release)
  • quartz: CONTAINER_APP_VERSION=1.28.2 (pinned nginx:1.28.2-alpine base)
  • All others: Existing versions carried forward with new uniform ARG pattern

Key Files

File Change
containers/*/Dockerfile Add ARG CONTAINER_APP_VERSION to all 13 containers
service-versions.yaml Populate current-version for devpi, cv, docs

Verification

  • Every container Dockerfile has ARG CONTAINER_APP_VERSION=X.Y.Z
  • ARG chaining tested with Docker build (nginx:1.28.2-alpine)
  • devpi container pins pip package versions
  • cv version matches Forgejo package release (1.0.3)
  • quartz pins nginx base image to stable (1.28.2)