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

Switch container builds to manual-only workflow dispatch

Browse source 
Shared Dagger helpers (src/blumeops/) affect all Dagger-built containers,
making path-based auto-triggers unreliable. All builds now go through
`mise run container-build-and-release <name>`.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erich Blume 2026-04-16 14:25:14 -07:00
commit 3ecd888537
6 changed files with 20 additions and 28 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -43,7 +43,7 @@ The runner job image contains the Dagger CLI binary. Upgrading it first means th
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.
3. Commit and push to main. Trigger a build with `mise run container-build-and-release runner-job-image`.
4. Verify the build succeeds — check the workflow run on Forgejo. Note the image tag from the build output (format: `v<version>-<sha>`).

6
docs/how-to/deployment/build-container-image.md
View file

@ -57,9 +57,9 @@ nix-build containers/<name>/default.nix -o result
## 3. Release
Container builds trigger automatically when changes to `containers/<name>/` are merged to `main`. Both workflows fire and each skips if the relevant build file is absent.
Container builds are triggered manually. Shared Dagger helpers (`src/blumeops/`) affect all Dagger-built containers, making path-based auto-triggers unreliable.
To trigger a manual build (e.g. from a branch or to rebuild at a specific commit):
To trigger a build:
```bash
mise run container-build-and-release <name>
@ -106,7 +106,7 @@ Container image tags include the git commit SHA they were built from (e.g. `v3.9
**The rule:** Production manifests must reference images built from a commit on main. After merging a PR that changed `containers/<name>/`:
1. The merge to main automatically triggers a rebuild (the `build-container.yaml` / `build-container-nix.yaml` workflows fire on pushes to `main` that touch `containers/**`)
1. Trigger a rebuild: `mise run container-build-and-release <name>`
2. Wait for the workflow to complete — verify with `mise run runner-logs` (find the run, check status)
3. Find the new main-SHA tag:
```bash

9
docs/how-to/zot/adopt-commit-based-container-tags.md
View file

@ -25,12 +25,11 @@ Currently, container builds trigger on git tags matching `<container>-vX.Y.Z`. T
### Triggers
1. **Merged changes to main** — any push to `main` that modifies files under `containers/<name>/` triggers builds for that container
2. **Manual workflow dispatch** — for ad-hoc builds. Accepts two inputs:
- `container` (required) — which container to build
- `ref` (optional, string) — the source commit SHA to build, defaulting to `GITHUB_SHA`
All container builds are triggered manually via `mise run container-build-and-release <name>` (which dispatches the workflow). Accepts two inputs:
- `container` (required) — which container to build
- `ref` (optional, string) — the source commit SHA to build, defaulting to `GITHUB_SHA`
Both the Dockerfile and Nix workflows fire for each trigger, each bailing out if the container lacks the relevant build file (same as today).
The workflow classifies the container by build type and routes to the correct runner.
### Version Source