ci: Use docker-tags composite action for multi-channel release support #68

cal · 2026-03-05T21:41:25Z

cal commented

2026-03-05 21:41:25 +00:00

Summary

Replaces separate dev/production Docker build steps with the shared docker-tags composite action for centralized tag resolution
Adds next-release branch trigger for RC builds (next-release, <calver>-rc, <calver>-rc-<sha>)
Discord notifications now fire on both main and next-release channels

🤖 Generated with Claude Code

## Summary - Replaces separate dev/production Docker build steps with the shared `docker-tags` composite action for centralized tag resolution - Adds `next-release` branch trigger for RC builds (`next-release`, `<calver>-rc`, `<calver>-rc-<sha>`) - Discord notifications now fire on both `main` and `next-release` channels 🤖 Generated with [Claude Code](https://claude.com/claude-code)

cal added 1 commit 2026-03-05 21:41:26 +00:00

ci: Use docker-tags composite action for multi-channel release support 72df98936b

Adds next-release branch trigger and replaces separate dev/production
build steps with the shared docker-tags action for tag resolution.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

cal added the

ai-reviewing

label 2026-03-05 21:45:34 +00:00

cal reviewed 2026-03-05 21:46:44 +00:00

cal left a comment

AI Code Review

Files Reviewed

.gitea/workflows/docker-build.yml (modified)

Findings

Correctness

The consolidation from two conditional build steps to one unified step is correct. The old workflow already had push: true on both dev and production steps, so behavior is preserved — all builds push to Docker Hub.
The old summary had a misleading comment "_PR build - image not pushed to Docker Hub_" that was factually wrong (dev builds did push). Removing it is correct.
Tag parsing in the Build Summary step uses IFS=',' read -ra TAG_ARRAY <<< "${{ steps.tags.outputs.tags }}" — this works correctly assuming docker-tags outputs comma-separated tags, which is consistent with how docker/build-push-action consumes them.
The pull_request trigger still only targets main, so PRs-to-next-release won't trigger builds. This is correct per the RC-build-on-push design.
The docker-tags action (cal/gitea-actions/docker-tags@main) is an external dependency I can't inspect here. The workflow consumes steps.tags.outputs.tags, steps.tags.outputs.channel, and steps.tags.outputs.primary_tag — if those outputs aren't defined in the composite action, steps will silently use empty strings. Worth verifying those output names match the action's outputs: block.

Security

No issues. Secrets (DISCORD_WEBHOOK, DOCKERHUB_USERNAME, DOCKERHUB_TOKEN) are all referenced via ${{ secrets.* }}. No hardcoded credentials.

Style & Conventions

Clean consolidation. Single build step is easier to maintain than two conditional steps.
Channel output surfaced in the summary is a nice addition for observability.

Suggestions

The next-release push trigger will fire on every push to next-release (not just merges), which could generate a lot of RC builds during active development. Consider whether this is intentional or if a path filter/manual dispatch would be preferable for that branch.
If the docker-tags composite action ever fails or outputs an empty tag list, docker/build-push-action with tags: "" will error. No action needed unless you want defensive validation.

Verdict: COMMENT

Clean CI refactoring — logic is correct, security is fine, conventions are followed. The main unknown is whether cal/gitea-actions/docker-tags@main outputs exactly the field names consumed here (tags, channel, primary_tag). If that action is already tested and stable, this is ready to merge.

Automated review by Claude PR Reviewer

## AI Code Review ### Files Reviewed - `.gitea/workflows/docker-build.yml` (modified) ### Findings #### Correctness - The consolidation from two conditional build steps to one unified step is correct. The old workflow already had `push: true` on both dev and production steps, so behavior is preserved — all builds push to Docker Hub. - The old summary had a misleading comment `"_PR build - image not pushed to Docker Hub_"` that was factually wrong (dev builds did push). Removing it is correct. - Tag parsing in the Build Summary step uses `IFS=',' read -ra TAG_ARRAY <<< "${{ steps.tags.outputs.tags }}"` — this works correctly assuming `docker-tags` outputs comma-separated tags, which is consistent with how `docker/build-push-action` consumes them. - The `pull_request` trigger still only targets `main`, so PRs-to-`next-release` won't trigger builds. This is correct per the RC-build-on-push design. - The `docker-tags` action (`cal/gitea-actions/docker-tags@main`) is an external dependency I can't inspect here. The workflow consumes `steps.tags.outputs.tags`, `steps.tags.outputs.channel`, and `steps.tags.outputs.primary_tag` — if those outputs aren't defined in the composite action, steps will silently use empty strings. Worth verifying those output names match the action's `outputs:` block. #### Security - No issues. Secrets (`DISCORD_WEBHOOK`, `DOCKERHUB_USERNAME`, `DOCKERHUB_TOKEN`) are all referenced via `${{ secrets.* }}`. No hardcoded credentials. #### Style & Conventions - Clean consolidation. Single build step is easier to maintain than two conditional steps. - Channel output surfaced in the summary is a nice addition for observability. #### Suggestions - The `next-release` push trigger will fire on *every push* to `next-release` (not just merges), which could generate a lot of RC builds during active development. Consider whether this is intentional or if a path filter/manual dispatch would be preferable for that branch. - If the `docker-tags` composite action ever fails or outputs an empty tag list, `docker/build-push-action` with `tags: ""` will error. No action needed unless you want defensive validation. ### Verdict: COMMENT Clean CI refactoring — logic is correct, security is fine, conventions are followed. The main unknown is whether `cal/gitea-actions/docker-tags@main` outputs exactly the field names consumed here (`tags`, `channel`, `primary_tag`). If that action is already tested and stable, this is ready to merge. --- *Automated review by Claude PR Reviewer*

cal added

ai-reviewed

and removed

ai-reviewing

labels 2026-03-05 21:47:19 +00:00

cal merged commit ee324693b1 into next-release

2026-03-07 03:33:27 +00:00

cal deleted branch ci/docker-tags-multi-channel

2026-03-07 03:33:27 +00:00

cal referenced this issue from a commit

2026-03-07 03:33:29 +00:00

Merge pull request 'ci: Use docker-tags composite action for multi-channel release support' (#68) from ci/docker-tags-multi-channel into next-release