ci: add a dispatchable release and keep the README version in sync - #7
Conversation
Two independent failures broke the 0.2.0 release. The publish job died in hevi with "422 Invalid target_commitish parameter": chart-releaser posts an empty target_commitish unless --commit is passed, which hevi never did (tada5hi/hevi#60, fixed by tada5hi/hevi#61). Publishing was only reachable from a master push, so there was no way to retry it once the version bump had already been merged. The release workflow now also accepts a workflow_dispatch, with release-please skipped on that path, and a concurrency group so a manual run cannot race a push. The lint job died on helm-docs drift: release-please bumps Chart.yaml but not the generated README, whose badge still advertised 0.1.0. The README is now a release-please extra-file. Its generic updater rewrites only the first semver on an annotated line, so the version badge is hand-rolled to carry the version exactly once and to terminate it with "?" instead of the "-informational" color segment, which the updater would otherwise swallow as a prerelease suffix.
📝 WalkthroughWalkthroughThe release workflow now supports manual dispatches, concurrency control, and publishing after a skipped ChangesRelease automation
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
actor Operator
participant GitHubActions
participant releasePlease
participant publish
Operator->>GitHubActions: Manually dispatch workflow
GitHubActions->>releasePlease: Skip job for non-push event
GitHubActions->>publish: Run after skipped release-please job
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Pull request overview
Updates the release automation for the Authup Helm chart to make publishing recoverable via manual dispatch and to keep the generated chart README’s version badge in sync with Chart.yaml, preventing helm-docs drift failures during release-please bumps.
Changes:
- Add
workflow_dispatchsupport (with concurrency) to the release workflow so publishing can be re-run without a new commit. - Configure release-please to update an additional file (
README.md) alongsideChart.yamlversion bumps. - Hand-roll the chart README version badge template so release-please can reliably update it without interfering with the
AppVersionbadge.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
release-please-config.json |
Adds extra-files to keep a README updated during release-please version bumps. |
charts/authup/README.md.gotmpl |
Replaces chart.badgesSection with a release-please-friendly version badge layout. |
charts/authup/README.md |
Regenerates README to match the new badge layout and updated chart version. |
.github/workflows/release.yaml |
Adds manual dispatch + concurrency and adjusts job conditions so publish can run when release-please is skipped. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| needs: release-please | ||
| # release-please is skipped on workflow_dispatch, and a skipped dependency | ||
| # would skip this job too without an explicit condition. | ||
| if: ${{ !cancelled() && needs.release-please.result != 'failure' }} |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.yaml:
- Around line 7-10: Restrict the workflow_dispatch recovery path in the release
workflow to trusted release refs before any publishing occurs. Update the
manual-run flow around actions/checkout and hevi so it validates the selected
github.ref and commit against the protected release branch or otherwise requires
the repository’s approved release environment, while leaving the automated
release-please path unchanged.
🪄 Autofix
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 Plus
Run ID: 2f4f3c54-c1d9-413a-8608-571504bc1674
📒 Files selected for processing (4)
.github/workflows/release.yamlcharts/authup/README.mdcharts/authup/README.md.gotmplrelease-please-config.json
| # Re-run the publish step for whatever Chart.yaml currently holds, without a new | ||
| # commit: the recovery path when a publish failed on its own (a broken releaser, | ||
| # an API hiccup) after release-please already merged the version bump. | ||
| workflow_dispatch: |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== release workflow =="
if [ -f .github/workflows/release.yaml ]; then
cat -n .github/workflows/release.yaml
else
echo "missing .github/workflows/release.yaml"
fi
echo
echo "== workflow files =="
git ls-files .github/workflowsRepository: authup/helm
Length of output: 3042
🌐 Web query:
GitHub Actions manually run workflow workflow_dispatch branches tags action context github.ref GITHUB_ACTOR can only run workflows in trusted branches
💡 Result:
When using the workflow_dispatch event to manually trigger a GitHub Actions workflow, the workflow file must exist on the default branch of the repository [1][2]. This is a fundamental requirement for the workflow to be discoverable and manually triggerable via the GitHub UI, API, or CLI [1]. Regarding the concept of "trusted branches," this aligns with the recently introduced "Workflow execution protections" feature (available as of June 2026) [3]. These protections allow enterprise and repository administrators to define policies that restrict who can trigger workflows and which events are permitted [4][3]. Specifically, these policies can: 1. Limit workflow_dispatch triggers to specific roles (e.g., maintainers) to prevent unauthorized manual execution [4][3]. 2. Block untrusted actors from triggering workflows [4][3]. 3. Apply central policies that override individual workflow configurations [4][3]. While workflow_dispatch itself requires the workflow file to be on the default branch to function, the execution of the workflow can be further constrained by these administrative rules, which function as an "allow list" to ensure only trusted users or events can initiate specific workflows [4][3]. For context on the variables mentioned: - github.ref: This context variable provides the fully formed ref (branch or tag) that triggered the workflow run [5]. - GITHUB_ACTOR: This environment variable identifies the user or app that initiated the workflow [6]. If you are experiencing issues with workflows running on non-default branches, ensure the workflow file is present on the default branch and that your organization or repository policies do not restrict the workflow_dispatch event for your user role [1][4].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manually-run-a-workflow?tool=webui
- 2: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow
- 3: https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/
- 4: https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/actions-policies/workflow-execution-protections
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 6: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/variables.md
🌐 Web query:
GitHub Actions manually run workflow run workflow branch tag default branch checkout publish default branch
💡 Result:
To manually trigger a GitHub Actions workflow, you must use the workflow_dispatch event trigger in your workflow file [1][2]. According to official documentation, this event trigger only functions when the workflow file exists on the default branch of the repository [1][2]. Key details regarding manual workflows include: 1. Manual Triggering: Once configured with workflow_dispatch, you can manually run the workflow via the GitHub UI (Actions tab), GitHub CLI, or REST API [1][3]. 2. Branch/Tag Selection: When manually triggering a workflow via the GitHub UI, you can select the specific branch or tag you wish to run the workflow against using the Branch dropdown menu [1][3]. Similarly, when using the GitHub CLI or REST API, you specify the target ref (branch or tag) as a parameter [1][4]. 3. Checking Out Code: Within your workflow steps, you typically use the actions/checkout action [5]. By default, this action checks out the code from the reference (branch, tag, or SHA) that triggered the workflow [5]. If no specific ref is provided, it defaults to the repository's default branch [5]. While official documentation states the workflow file must reside on the default branch to be triggerable via workflow_dispatch [1][2], community workarounds often involve ensuring the workflow has run at least once on the default branch (e.g., via other triggers) to register it with the GitHub Actions system [6]. Always ensure your workflow includes the checkout step if you need to interact with the repository's source code for the selected branch or tag [5].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manually-run-a-workflow
- 2: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow
- 3: https://docs.github.com/actions/managing-workflow-runs/manually-running-a-workflow
- 4: https://docs.github.com/en/rest/actions/workflows
- 5: https://www.github.com/actions/checkout
- 6: https://andreynautilus.github.io/posts/2025-08-19-github-workflow_dispatch-from-branch/
Authorization Bypass (CWE-862): Missing Authorization
Reachability: External
Gate manual publication to trusted refs.
workflow_dispatch can target any selectable branch or tag. On manual run, release-please is skipped, actions/checkout checks out the selected github.ref, and hevi publishes that chart contents with write-access GITHUB_TOKEN. Restrict manual runs to protected release refs, validate the selected commit against a trusted branch before publishing, or require environment approval.
[security_and_privancy]
🤖 Prompt for 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.
In @.github/workflows/release.yaml around lines 7 - 10, Restrict the
workflow_dispatch recovery path in the release workflow to trusted release refs
before any publishing occurs. Update the manual-run flow around actions/checkout
and hevi so it validates the selected github.ref and commit against the
protected release branch or otherwise requires the repository’s approved release
environment, while leaving the automated release-please path unchanged.
The 0.2.0 release failed twice over, for two unrelated reasons.
1. publish:
422 Invalid target_commitish parameterhevi invoked
cr uploadwithout--commit, so chart-releaser posted an emptytarget_commitishand the GitHub API rejected the release (run 30939094583).
Filed and fixed upstream: tada5hi/hevi#60 / tada5hi/hevi#61.
@v2floats, so this repo picks thefix up once that release lands.
Earlier runs were green only because
--skip-existingskipped the already-released 0.1.0, so thebug surfaced on the first version bump after the hevi migration.
Publishing was reachable only from a master push, leaving no way to retry after the version
bump had already merged.
workflow_dispatchnow provides that recovery path (dispatch on any ref;Chart.yaml stays the version source, so no version input is needed). release-please is skipped on
the dispatch path, and
publishgets an explicit condition because a skipped dependency wouldotherwise skip it too. A concurrency group keeps a manual run from racing a push.
2. lint: helm-docs drift
release-please bumps
Chart.yamlbut not the generated README, whose badge still read 0.1.0, sothe drift gate failed. The README is now a release-please
extra-filesentry.The version badge had to be hand-rolled rather than using
chart.badgesSection, becauserelease-please's generic updater rewrites only the first semver on an annotated line:
?instead of the usual-informationalcolor segment: theupdater's regex reads
0.2.0-informationalas version + prerelease and would drop the colorVerification
make testpasses (lint, render matrix over everyci/*-values.yaml, values coverage)make docs schemaleaves a clean tree, so both CI drift gates passdiffing it against what helm-docs actually emits for 0.3.0: byte-identical, so the next
release-please PR will not re-break the drift gate
Summary by CodeRabbit
Release Automation
Documentation