Skip to content

ci: add a dispatchable release and keep the README version in sync #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tada5hi merged 1 commit into from
Aug 4, 2026
Merged

ci: add a dispatchable release and keep the README version in sync #7

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions .github/workflows/release.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,12 @@ on:
push:
branches:
- master
# 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:
Comment on lines +7 to +10

@coderabbitai coderabbitai Bot Aug 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 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/workflows

Repository: 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:

🌐 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:

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.


concurrency: ${{ github.workflow }}-${{ github.ref }}

permissions:
contents: write
Expand All @@ -13,6 +19,7 @@ permissions:
jobs:
release-please:
runs-on: ubuntu-latest
if: github.event_name == 'push'
steps:
- uses: googleapis/release-please-action@v4
id: release
Expand All @@ -28,6 +35,9 @@ jobs:
publish:
runs-on: ubuntu-latest
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' }}
steps:
- name: Checkout
uses: actions/checkout@v4
Expand Down
3 changes: 2 additions & 1 deletion charts/authup/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@

# authup

![Version: 0.1.0](https://img.shields.io/badge/Version-0.1.0-informational?style=flat-square) ![Type: application](https://img.shields.io/badge/Type-application-informational?style=flat-square) ![AppVersion: 1.0.0-beta.58](https://img.shields.io/badge/AppVersion-1.0.0--beta.58-informational?style=flat-square)
![Version](https://img.shields.io/badge/Version-0.2.0?style=flat-square&color=informational) <!-- x-release-please-version -->
![Type: application](https://img.shields.io/badge/Type-application-informational?style=flat-square) ![AppVersion: 1.0.0-beta.58](https://img.shields.io/badge/AppVersion-1.0.0--beta.58-informational?style=flat-square)

Authup is an authentication & authorization system. This chart deploys the server-core IdP/API service and the client-admin-console admin UI, with optional built-in PostgreSQL, MySQL and Valkey instances. It deploys:

Expand Down
14 changes: 13 additions & 1 deletion charts/authup/README.md.gotmpl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,19 @@

{{ template "chart.deprecationWarning" . }}

{{ template "chart.badgesSection" . }}
{{/*
The version badge is hand-rolled instead of using chart.badgesSection, because
release-please has to keep it in sync with Chart.yaml (it is listed as an
extra-file). Two constraints come from its generic updater, which rewrites only
the FIRST semver on an annotated line:
1. the version may appear exactly once here, so the appVersion badge has to
live on a separate line
2. the version has to be terminated by "?", not by the usual "-informational"
color segment, which the updater would otherwise swallow as a semver
prerelease suffix and drop
*/}}
![Version](https://img.shields.io/badge/Version-{{ template "chart.version" . }}?style=flat-square&color=informational) <!-- x-release-please-version -->
{{ template "chart.typeBadge" . }}{{ template "chart.appVersionBadge" . }}

{{ template "chart.description" . }} It deploys:

Expand Down
5 changes: 4 additions & 1 deletion release-please-config.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,10 @@
"charts/authup": {
"component": "authup",
"release-type": "helm",
"skip-github-release": true
"skip-github-release": true,
"extra-files": [
"README.md"
]
}
}
}
Loading