eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions

Native Dagger container builds + Navidrome v0.61.1 (#330)
All checks were successful
Build Container / detect (push) Successful in 3s
Details
Build Container / build-dagger (navidrome) (push) Successful in 22m26s
Details

Browse source 
## 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
This commit is contained in:
Erich Blume 2026-04-11 17:11:56 -07:00
commit c86b5d7772
33 changed files with 422 additions and 929 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/how-to/dagger/upgrade-dagger.md
View file

@ -1,6 +1,6 @@
---
title: Upgrade Dagger
modified: 2026-03-06
modified: 2026-04-11
last-reviewed: 2026-03-06
tags:
- how-to
@ -26,7 +26,7 @@ Dagger versions are pinned in multiple places. The runner job image (which execu
| `service-versions.yaml` | `runner-job-image` version and `last-reviewed` | 1 |
| `mise.toml` | `dagger` tool version | 2 |
| `dagger.json` | `engineVersion` | 2 |
| `.dagger/uv.lock` | SDK dependency lock (regenerated automatically) | 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 |
@ -63,7 +63,7 @@ Once the Phase 1 build completes, upgrade the module engine version and deploy t
"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 `.dagger/uv.lock` if SDK dependencies changed.
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.