ci: allow workflow_dispatch on the release workflow

[phanan]

Mirrors what koel/franken's release workflow already does: accept a koel_version input via workflow_dispatch so a release build can be re-triggered against any Koel tag without pushing a fresh git tag.

Why it matters: today, if the production image build fails (network blip, draft koel/koel release not yet published, etc.), the only recovery path is gh run rerun <id> against the original failed run — which only works while the run is still in retention. After 90 days, the run vanishes and the only recourse is to push a phantom git tag.

With this in place, recovery is gh workflow run release.yml --repo koel/docker -f koel_version=vX.Y.Z.

Implementation

• workflow_dispatch with a required koel_version input
• Resolve version step picks inputs.koel_version when present, otherwise github.ref_name (preserves existing tag-push behavior exactly)
• build-args: KOEL_VERSION_REF=... is now passed through to docker build, so the workflow value wins over the Dockerfile's ARG default. For tag-push runs the two values are identical; for dispatch runs the Dockerfile's pinned version is overridden.

Test plan

• Tag-push behavior: next release via ./release vX.Y.Z still works as before
• Dispatch behavior: gh workflow run release.yml -f koel_version=v9.4.0 re-builds v9.4.0 cleanly

Summary by CodeRabbit

• Chores
  • Release workflow now supports manual version entry when triggering a release, with automatic fallback to the current ref when omitted.
  • Resolved release version and tag are emitted and propagated to deployment steps.
  • Docker image builds receive the resolved release tag as a build argument while published image tags remain version-only.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: eef17ac3-9846-4c76-91e4-1f3fa4e23ebe

📥 Commits

Reviewing files that changed from the base of the PR and between 64741c3 and 6d46ab1.

📒 Files selected for processing (1)

• .github/workflows/release.yml

---

📝 Walkthrough

Walkthrough

The release workflow adds a required workflow_dispatch input koel_version. The deploy job resolves VERSION (no leading v) and TAG from that input or from the ref name, and passes TAG into the Docker build as the KOEL_VERSION_REF build-arg.

Changes

Release Version Input and Resolution

Layer / File(s)	Summary
Release version input and Docker build configuration .github/workflows/release.yml	Adds a required manual koel_version input; deploy job resolves VERSION and TAG preferring inputs.koel_version with fallback to GITHUB_REF_NAME; exposes outputs VERSION and TAG and passes TAG into Docker build as KOEL_VERSION_REF, tagging images with VERSION.

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I tap the dispatch, soft and light,
Type a tag to launch the night,
If empty, I trace the branch instead,
Then feed the build the tag you've said,
Images tagged and hoppity—delight!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the primary change: enabling manual workflow dispatch on the release workflow, which matches the main objective of adding workflow_dispatch to the release CI workflow.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/workflow-dispatch-release

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yml:
- Around line 48-54: The step "Resolve version" currently expands the workflow
template directly in the shell which risks template injection; instead move the
template expressions into the step's env block (e.g., set KOEL_VERSION: "${{
inputs.koel_version }}" and GITHUB_REF_NAME: "${{ github.ref_name }}"), then in
the run script reference those safe env vars and perform the fallback in-shell
using POSIX parameter expansion (use REF derived from KOEL_VERSION and
GITHUB_REF_NAME like REF="${KOEL_VERSION:-$GITHUB_REF_NAME}"), ensure you quote
variables when echoing outputs and write VERSION and TAG to GITHUB_OUTPUT using
the existing keys VERSION and TAG to preserve behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: f0b06695-b2fb-4b60-9f8f-57fabad522ab

📥 Commits

Reviewing files that changed from the base of the PR and between 27a5d57 and 7fb09c4.

📒 Files selected for processing (1)

• .github/workflows/release.yml