Erich Blume
c86b5d7772
## 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
112 lines
4.6 KiB
Markdown
112 lines
4.6 KiB
Markdown
---
|
|
title: Upgrade Dagger
|
|
modified: 2026-04-11
|
|
last-reviewed: 2026-03-06
|
|
tags:
|
|
- how-to
|
|
- dagger
|
|
- ci-cd
|
|
---
|
|
|
|
# Upgrade Dagger
|
|
|
|
How to upgrade the Dagger engine and CLI across all components in BlumeOps. The ordering matters — upgrading in the wrong sequence creates a chicken-and-egg problem where CI can't build its own replacement.
|
|
|
|
## Overview
|
|
|
|
Dagger versions are pinned in multiple places. The runner job image (which executes CI workflows) contains the Dagger CLI, and the module's `dagger.json` declares the engine version. These must match — if the CLI is older than the engine version, Dagger refuses to run.
|
|
|
|
**Key insight:** Upgrade the runner container *first* (with the new CLI but the old engine version), deploy it, and *then* bump the engine version. This avoids needing a local build to break the cycle.
|
|
|
|
## Files to update
|
|
|
|
| File | What | Phase |
|
|
|------|------|-------|
|
|
| `containers/runner-job-image/Dockerfile` | `CONTAINER_APP_VERSION` (CLI version) | 1 |
|
|
| `service-versions.yaml` | `runner-job-image` version and `last-reviewed` | 1 |
|
|
| `mise.toml` | `dagger` tool version | 2 |
|
|
| `dagger.json` | `engineVersion` | 2 |
|
|
| `uv.lock` | SDK dependency lock (regenerated automatically) | 2 |
|
|
| `docs/reference/tools/dagger.md` | Version references in documentation | 2 |
|
|
| `argocd/manifests/forgejo-runner/deployment.yaml` | `RUNNER_LABELS` image tag | 2 |
|
|
|
|
## Procedure
|
|
|
|
### Phase 1: Upgrade the runner job image
|
|
|
|
The runner job image contains the Dagger CLI binary. Upgrading it first means the current CI (still on the old engine version) can build and publish the new image normally.
|
|
|
|
1. Update `containers/runner-job-image/Dockerfile`:
|
|
```dockerfile
|
|
ARG CONTAINER_APP_VERSION=<new-version>
|
|
```
|
|
|
|
2. Update `service-versions.yaml` — bump `current-version` and `last-reviewed` for `runner-job-image`.
|
|
|
|
3. Commit and push to main. The `Build Container` workflow triggers automatically (it watches `containers/**`), building and publishing the new runner-job-image with the updated Dagger CLI.
|
|
|
|
4. Verify the build succeeds — check the workflow run on Forgejo. Note the image tag from the build output (format: `v<version>-<sha>`).
|
|
|
|
### Phase 2: Upgrade the module and deploy the new runner
|
|
|
|
Once the Phase 1 build completes, upgrade the module engine version and deploy the new runner in a single commit. None of these paths trigger CI workflows automatically, so there is no race condition.
|
|
|
|
1. Update `mise.toml`:
|
|
```toml
|
|
dagger = "<new-version>"
|
|
```
|
|
|
|
2. Run `mise install` to get the new CLI locally.
|
|
|
|
3. Update `dagger.json`:
|
|
```json
|
|
"engineVersion": "v<new-version>"
|
|
```
|
|
|
|
4. Regenerate the SDK lock file — run any `dagger call` command (e.g., `dagger call --help` or `dagger functions`). This updates `uv.lock` if SDK dependencies changed.
|
|
|
|
5. Update `docs/reference/tools/dagger.md` — bump the version in the Quick Reference table and any version references in the body text.
|
|
|
|
6. Update `argocd/manifests/forgejo-runner/deployment.yaml` — set the `RUNNER_LABELS` value to use the new image tag from Phase 1:
|
|
```yaml
|
|
value: "k8s:docker://registry.ops.eblu.me/blumeops/runner-job-image:<tag>"
|
|
```
|
|
|
|
7. Commit and push to main.
|
|
|
|
8. Sync the forgejo-runner app:
|
|
```fish
|
|
argocd app sync forgejo-runner
|
|
```
|
|
|
|
9. Verify the runner is healthy:
|
|
```fish
|
|
argocd app get forgejo-runner
|
|
```
|
|
|
|
10. Test CI by triggering a workflow (e.g., manual dispatch of `Build BlumeOps`).
|
|
|
|
## Why the order matters
|
|
|
|
The Dagger CLI refuses to run a module whose `engineVersion` is newer than the CLI version. If you upgrade `dagger.json` first:
|
|
|
|
1. CI tries to run `dagger call` with the old CLI
|
|
2. The module declares a newer engine version
|
|
3. Dagger exits with a version mismatch error
|
|
4. The `Build Container` workflow can't run — so you can't build the new runner image via CI
|
|
5. You're stuck: the runner can't build its own replacement
|
|
|
|
By upgrading the CLI in the runner image first (Phase 1), the current engine version (old) still works fine with the newer CLI. Phase 2 combines the engine version bump with the runner deployment in a single commit — this is safe because none of the changed paths (`dagger.json`, `mise.toml`, `argocd/manifests/forgejo-runner/`) trigger CI workflows automatically. Just sync the forgejo-runner app before triggering any workflows.
|
|
|
|
## Changelog
|
|
|
|
Add a changelog fragment: `docs/changelog.d/+upgrade-dagger-<version>.<type>.md`
|
|
|
|
Use type `infra` for routine upgrades. Include both the old and new versions in the description.
|
|
|
|
## Related
|
|
|
|
- [[dagger]] — Dagger reference card
|
|
- [[build-container-image]] — How container builds work
|
|
- [[update-tooling-dependencies]] — General tooling update procedure
|
|
- [[forgejo]] — CI/CD platform
|