You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR adds a new GitHub Actions workflow that automates the creation of release tags with semantic versioning. The workflow allows maintainers to manually trigger a patch or minor version bump, which automatically:
Bumps the version in package.json using npm version
Creates and pushes a git tag
Ensures the workflow only runs on the master branch
Uses a Personal Access Token (PAT) to ensure pushed tags trigger downstream release workflows
The workflow includes proper git configuration, Node.js setup, and provides a summary of the created release in the GitHub Actions job summary.
Added a manual release workflow for patch and minor versions. It validates master, bumps the package version, pushes the commit and tag atomically, dispatches release workflows, and limits production Docker builds to version tags.
Changes
Manual release and workflow dispatch
Layer / File(s)
Summary
Release trigger and permissions .github/workflows/create-release-tag.yml, .github/workflows/build-demo-website.yml, .github/workflows/docker-release-build.yml
The release workflow defines patch and minor inputs, permissions, and concurrency control. The Docker and demo website workflows support manual dispatch.
Release preparation and version bump .github/workflows/create-release-tag.yml
The release job validates master, checks out full history, configures Node.js and Git, and runs the selected version bump.
Tag publishing and release dispatch .github/workflows/create-release-tag.yml, .github/workflows/docker-release-build.yml
The workflow pushes the commit and tag atomically, dispatches three release workflows, and writes release details to the job summary. The Docker production job runs only for version tags.
sequenceDiagram
participant GitHubActions as GitHub Actions
participant GitHubRepository as GitHub repository
participant ReleaseWorkflows as Release workflows
participant DockerJob as Docker production job
GitHubActions->>GitHubRepository: Push master commit and generated tag atomically
GitHubActions->>ReleaseWorkflows: Dispatch release workflows on the tag
ReleaseWorkflows->>DockerJob: Run production build only for refs/tags/v
GitHubActions->>GitHubActions: Write release details to job summary
Loading
Poem
A rabbit starts the release run,
Patch or minor, neatly done.
The tag hops out on master’s trail,
Release workflows lift their sail.
Docker builds when version tags prevail.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Review: Create release tag workflow
Useful automation that matches the existing manual release pattern (npm version bump of root package.json + package-lock.json, commit message like 4.84.1, tag v*.*.* → docker-release-build.yml). Master-only guard, patch/minor-only choices, and bot commit identity look good.
Not approving yet — please address the silent GITHUB_TOKEN fallback (and ideally concurrency) before merge. Without RELEASE_PAT, a green run creates a tag that does not trigger the production release workflows this PR exists to drive.
No Gladys runtime / device-constants impact → no risk:high / needs:human-review.
The summary expands step outputs and workflow metadata directly into Bash. Pass these values through env and use quoted printf arguments. GitHub evaluates context expressions before the runner executes the script. (docs.github.com)
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/create-release-tag.yml around lines 53 - 58, Update the
“📝 Job summary” step to pass the release version, release type, server URL, and
repository through an env block, then write the summary using quoted printf
arguments instead of interpolating GitHub expressions directly in the Bash
source. Preserve the existing headings, bump type, and release-tag link output.
The downstream workflow matches only v*.*.* tags. npm 10 defaults to the v prefix, but npm configuration can override tag-version-prefix. Pass the input through env, validate patch or minor, and set --tag-version-prefix=v explicitly. (docs.npmjs.com)
🏷️ Proposed fix
- name: 🔖 Bump version and create tag
id: bump
+ env:+ RELEASE_TYPE: ${{ inputs.release_type }}
run: |
- NEW_VERSION=$(npm version ${{ inputs.release_type }})+ case "$RELEASE_TYPE" in+ patch|minor) ;;+ *) echo "Unsupported release type" >&2; exit 1 ;;+ esac+ NEW_VERSION=$(npm version --tag-version-prefix=v "$RELEASE_TYPE")
🤖 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/create-release-tag.yml around lines 44 - 49, Update the
“Bump version and create tag” step to pass the release type through its
environment, validate that it is only patch or minor, and invoke npm version
with an explicit v tag-version prefix so generated tags always match v*.*.*.
actions/checkout@v4 persists the supplied token for later Git commands by default. This makes the write-capable PAT available to later steps, including package lifecycle scripts. Set persist-credentials: false and configure a temporary credential only in the push step. Do not add the flag without updating the push authentication. (github.com)
🤖 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/create-release-tag.yml around lines 29 - 35, Update the
checkout configuration in the “⬇️ Checkout Gladys code” step to set
persist-credentials to false, then update the later tag-push step to
authenticate explicitly with the release PAT only for that push operation,
preserving the existing fallback behavior where applicable.
Source: Linters/SAST tools
🤖 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/create-release-tag.yml:
- Around line 19-22: Add a workflow-level concurrency configuration for
create-release-tag, using a release-specific group and setting
cancel-in-progress to false so manually dispatched release runs queue instead of
overlapping. Keep the existing create-release-tag job configuration unchanged.
- Around line 29-35: Update the checkout step in the release workflow to require
secrets.RELEASE_PAT directly, removing the fallback to secrets.GITHUB_TOKEN.
Preserve the existing token usage so checkout and subsequent git push operations
fail when RELEASE_PAT is unavailable.
- Around line 24-28: Move the master-branch restriction from the “🛑 Ensure
workflow runs on master” step to the job-level if condition, preventing the job
from starting for other refs. Update the checkout action to explicitly target
refs/heads/master, and remove the shell-based github.ref_name interpolation and
late branch guard.
- Around line 50-52: Update the “🚀 Push commit and tag” step to use Git’s
atomic push option so the release commit and tags succeed or fail together. Also
ensure this workflow is serialized with other release or branch-update workflows
using the repository’s existing concurrency mechanism, preventing simultaneous
ref updates.
---
Nitpick comments:
In @.github/workflows/create-release-tag.yml:
- Around line 53-58: Update the “📝 Job summary” step to pass the release
version, release type, server URL, and repository through an env block, then
write the summary using quoted printf arguments instead of interpolating GitHub
expressions directly in the Bash source. Preserve the existing headings, bump
type, and release-tag link output.
- Around line 44-49: Update the “Bump version and create tag” step to pass the
release type through its environment, validate that it is only patch or minor,
and invoke npm version with an explicit v tag-version prefix so generated tags
always match v*.*.*.
- Around line 29-35: Update the checkout configuration in the “⬇️ Checkout
Gladys code” step to set persist-credentials to false, then update the later
tag-push step to authenticate explicitly with the release PAT only for that push
operation, preserving the existing fallback behavior where applicable.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b17cbd1b-71dc-4a9b-ad78-9d1a38fe3db3
📥 Commits
Reviewing files that changed from the base of the PR and between bd9342a and 0a483cf.
GitHub Actions run workflow button select branch workflow_dispatch manual runs on branch security bash injection github.ref_name
💡 Result:
Using ${{ github.ref_name }} or workflow inputs directly within a bash run block is a significant security risk, classified as template or shell command injection [1][2][3]. When you place these expressions directly into a run block, the GitHub Actions runner replaces the placeholders with their raw string values before the shell executes the command [4][2][5]. An attacker can craft a branch name or workflow input containing shell meta-characters (such as ;, &, |, or backticks) to break out of your intended command and execute arbitrary code on the runner [1][6][3]. To secure your workflows, you must never interpolate untrusted values directly into run scripts [1][2][5]. Instead, follow these industry-standard defensive practices: 1. Use Environment Variables: Map all untrusted inputs (including github.ref_name and workflow_dispatch inputs) to environment variables at the step level [4][6][7]. This ensures the values are treated as data, not code, by the shell [2][6][8]. Example of secure implementation: - name: Process branch name env: BRANCH_NAME: ${{ github.ref_name }} run: | # Use the variable in quotes to prevent shell interpretation echo "Processing branch: $BRANCH_NAME" 2. Input Validation: For workflow_dispatch inputs, implement strict validation using regular expressions or allowlists before the input is used in any downstream logic [4][9][6]. For example, ensure a version input matches a known pattern (e.g., ^[a-zA-Z0-9._-]+$) [4][6]. 3. Static Analysis: Enable code scanning with CodeQL in your repository [2][5]. CodeQL includes specialized queries designed to detect unsafe interpolation of untrusted inputs into GitHub Actions workflows, helping you catch these vulnerabilities before they are exploited [2][5]. By treating all inputs—including branch names, issue titles, and workflow_dispatch fields—as untrusted, you significantly reduce the risk of supply chain compromise and credential exfiltration [1][4][6].
npm version lifecycle scripts runs lifecycle scripts prepublish preversion version postversion
💡 Result:
In the npm lifecycle, scripts are triggered by specific commands to manage package preparation, versioning, and publishing [1][2]. Version Lifecycle Scripts When running the npm version command, the lifecycle scripts execute in the following fixed order [1][2]: 1. preversion: Runs before the package version is bumped [3][4]. 2. version: Runs after the version is bumped, but before the commit [3][4]. 3. postversion: Runs after the version is bumped and after the commit [3][4]. Prepublish and Related Scripts The prepublish script is considered deprecated because its behavior can be confusing; it runs both before the package is packed/published and during a local npm install without arguments [3][1]. To replace this, npm introduced other lifecycle events [3][1]: - prepublishOnly: Runs only before the package is prepared and packed, specifically during npm publish [3][1]. - prepare: Runs after prepublish, but before prepublishOnly. It executes during both npm publish and local npm install, serving as a reliable alternative for build steps [3][1]. General Note For any script (e.g., myscript), npm automatically looks for pre- and post- counterparts (premyscript and postmyscript) if they are defined in your package.json [1][2]. Additionally, the environment variable npm_lifecycle_event is always set to the name of the script currently being executed, allowing you to use a single script to handle multiple lifecycle stages [3][1].
GitHub Actions workflow_dispatch manual run select workflow branch if condition github.ref jobs job if
💡 Result:
When using workflow_dispatch to run a GitHub Actions workflow manually, the GitHub UI allows you to select any branch in the repository as the target for the workflow execution [1][2]. For the manual branch selection to function, the workflow file must exist in the default branch of the repository [1][3]. Once triggered, the workflow execution context identifies the selected branch through standard GitHub context variables [2]. You can use the github.ref or github.ref_name context variables within your workflow to dynamically handle the selected branch [2]. To restrict or control job execution based on the branch selected during the manual run, you can use the jobs.<job_id>.if condition [4][3]. Example implementation using a conditional job: jobs: deploy: runs-on: ubuntu-latest # This job will only run if the branch selected in the manual UI is 'main' if: ${{ github.ref_name == 'main' }} steps: - uses: actions/checkout@v4 - run: echo "Running on ${{ github.ref_name }}" If you need to control the branch used by the actions/checkout step itself (for example, to support scheduled runs alongside manual runs), you can use a ternary expression to dynamically set the ref [2]: jobs: checkout-job: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: # Use 'main' for scheduled runs, or the selected branch for manual runs ref: ${{ github.event_name == 'schedule' && 'main' || github.ref_name }}
Move the branch restriction and checkout target outside untrusted output.
.github/workflows/create-release-tag.yml allows manual dispatch on any branch. Interpolating github.ref_name into the shell can allow command injection, and npm version can run lifecycle scripts from the selected repository state before the guard exits. Apply the check at job level and force checkout to refs/heads/master.
🧰 Tools🪛 zizmor (1.28.0)
[error] 27-27: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
🤖 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/create-release-tag.yml around lines 24 - 28, Move the
master-branch restriction from the “🛑 Ensure workflow runs on master” step to
the job-level if condition, preventing the job from starting for other refs.
Update the checkout action to explicitly target refs/heads/master, and remove
the shell-based github.ref_name interpolation and late branch guard.
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.15%. Comparing base (bd9342a) to head (a25fc84). ⚠️ Report is 3 commits behind head on master.
- Require the RELEASE_PAT secret instead of silently falling back to
GITHUB_TOKEN, which would create a tag that never triggers the release build
- Add a concurrency group so two dispatches cannot bump from the same tip
- Checkout the current tip of master rather than the dispatch-time commit
- Push the commit and the tag atomically
- Pass refs and inputs through env vars instead of interpolating them in shell
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NpWWjywQsozhFp7pgsz1Cy
The reason will be displayed to describe this comment to others. Learn more.
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/create-release-tag.yml:
- Around line 46-55: Update the checkout step in the release workflow to use
github.token for its token and set persist-credentials to false. Remove
RELEASE_PAT from actions/checkout, then pass it only to the final atomic git
push via a one-shot http.extraheader.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 108f6938-19a5-4a20-82b1-a3de0f950ffe
📥 Commits
Reviewing files that changed from the base of the PR and between 0a483cf and 7e13fcf.
Checkout now runs with the default GITHUB_TOKEN and persist-credentials
disabled. RELEASE_PAT is only passed to the final push, through a one-shot
masked authentication header.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NpWWjywQsozhFp7pgsz1Cy
Checkout tip of master with persist-credentials: false, PAT only on the final atomic push via one-shot http.extraheader
Atomic push of the version commit + v*.*.* tag
This matches the existing manual release pattern (root package.json / lockfile bump, bare-semver commit, v-prefixed tag → production image pipeline). No Gladys runtime / device-taxonomy changes; not risk:high / not needs:human-review.
Ops reminder (not a merge blocker): ensure RELEASE_PAT can push to protected master and create tags. An optional GitHub Environment with required reviewers remains a nice hardening if you want a second human checkpoint before shipping production images.
A tag pushed with the default GITHUB_TOKEN does not start the workflows
listening on `push: tags`, which is why a PAT was required. workflow_dispatch
is one of the two events GitHub does start from a GITHUB_TOKEN, so the release
workflows are now dispatched explicitly on the new tag instead.
- Drop the RELEASE_PAT secret entirely
- Add workflow_dispatch to the production image and demo website workflows
- Only publish production images from a release tag, never from a branch a
manual dispatch could have been started on
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NpWWjywQsozhFp7pgsz1Cy
The reason will be displayed to describe this comment to others. Learn more.
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/docker-release-build.yml:
- Around line 127-129: Update the Docker publish condition around the docker job
to require the prerelease validation job and an exact supported release-tag
format, rather than only the refs/tags/v prefix. Allow production publishing
only for vMAJOR.MINOR.PATCH tags, while permitting prerelease jobs to publish
supported forms such as vMAJOR.MINOR.PATCH-next.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: bb2bb359-33ce-462a-b8dc-81ab7f5fec7b
📥 Commits
Reviewing files that changed from the base of the PR and between f35e27a and a25fc84.
#!/bin/bashset -euo pipefail
echo"== inspect release workflow context =="
python3 - <<'PY'from pathlib import Pathp=Path('.github/workflows/docker-release-build.yml')if not p.exists(): print('missing') raise SystemExitlines=p.read_text().splitlines()for i,l in enumerate(lines,1): if 'workflow_dispatch' in l or 'push:' in l or 'pull_request:' in l or any(kw in l for kw in ['if:', 'refs/tags', 'docker', 'needs:']): print(f"{i}: {l}")PY
In GitHub Actions, the workflow_dispatch event allows you to manually trigger a workflow [1][2]. While you can define custom inputs for this event, the ref (reference) is a distinct parameter used to specify which branch, tag, or commit SHA the workflow should run against [1][3]. Key Concepts regarding Ref and Inputs: 1. The Ref Parameter: The ref is not defined as an input within your YAML workflow file's inputs section [4]. Instead, it is a required parameter provided when triggering the workflow via the GitHub UI, GitHub CLI, or REST API [1][2][3]. - GitHub UI: You select the branch or tag from a dropdown menu after clicking the Run workflow button [2]. - GitHub CLI: You use the --ref flag (e.g., gh workflow run WORKFLOW --ref BRANCH_OR_TAG) [1][2]. - REST API: You include it as a mandatory field in the request body (e.g., "ref": "main") [5][3]. 2. Inputs: You can define up to 25 custom inputs in your workflow YAML file under the on.workflow_dispatch.inputs key [1][4][3]. These inputs are separate from the Git ref [4][3]. Example of triggering via REST API: You must provide the ref as a top-level key in the JSON payload, while custom inputs reside within their own inputs object [3]. curl -L -X POST https://api.github.com/repos/OWNER/REPO/actions/workflows/WORKFLOW_ID/dispatches \ -d '{ "ref": "main", "inputs": { "logLevel": "warning", "tags": "production-release" } }' If you need to pass a tag or branch dynamically as an input, you must define a string input in your YAML (e.g., named target_ref) and manually handle that value within your workflow steps, as the system-level ref parameter used by the trigger mechanism is not automatically mapped to custom input fields [4].
Require an exact release-tag format before publishing images.
The Docker job runs when workflow_dispatch is invoked with any refs/tags/v* ref because startsWith(github.ref, 'refs/tags/v') only checks the prefix. Gate docker on a prerelease job that validates github.ref against the release tag grammar, such as vMAJOR.MINOR.PATCH, and let prerelease jobs publish only vMAJOR.MINOR.PATCH-next or another supported prerelease form.
🤖 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/docker-release-build.yml around lines 127 - 129, Update
the Docker publish condition around the docker job to require the prerelease
validation job and an exact supported release-tag format, rather than only the
refs/tags/v prefix. Allow production publishing only for vMAJOR.MINOR.PATCH
tags, while permitting prerelease jobs to publish supported forms such as
vMAJOR.MINOR.PATCH-next.
The reason will be displayed to describe this comment to others. Learn more.
Re-review @ a25fc84: approve
The design shift away from a long-lived RELEASE_PAT is a solid improvement. Pushing the version commit + tag with GITHUB_TOKEN, then explicitly gh workflow run … --ref <tag> on the three release workflows, correctly works around GitHub’s “GITHUB_TOKEN pushes do not start push workflows” rule without storing a write PAT.
No Gladys runtime / device-constants impact → not risk:high / not needs:human-review. Soft residuals called out inline (demo branch dispatch; confirm GITHUB_TOKEN can push protected master).
The reason will be displayed to describe this comment to others. Learn more.
Soft (parity with Docker):workflow_dispatch here has no tag/ref guard, so anyone with Actions write can publish the demo site from an arbitrary branch via the UI. docker-release-build.yml correctly skips publishing unless github.ref is a refs/tags/v* ref. Apidoc already had the same ungated dispatch before this PR, so this is not a merge blocker — consider mirroring the Docker-style if: on the deploy job if you want demo publishes limited to release tags.
The reason will be displayed to describe this comment to others. Learn more.
Ops reminder (not a merge blocker): this push now uses the default GITHUB_TOKEN (contents: write) instead of a PAT. Confirm branch protection / rulesets allow GitHub Actions to push commits and tags to master; if not, the job fails closed (atomic push), but the workflow will not ship until that is allowed (or an Environment with a bypass actor is configured).
Optional hardening still stands: pin this job to a GitHub Environment with required reviewers so “Create release tag” is not a one-click production ship for every collaborator with write access.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
area:infraCI, Docker, release, deploymenttype:choreDeps, CI, refactoring, docs. Hidden from user changelog
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
area:infra
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Pierre-Gilles
added
needs:cursor-review
Description
This PR adds a new GitHub Actions workflow that automates the creation of release tags with semantic versioning. The workflow allows maintainers to manually trigger a patch or minor version bump, which automatically:
package.jsonusingnpm versionThe workflow includes proper git configuration, Node.js setup, and provides a summary of the created release in the GitHub Actions job summary.
Checklist
https://claude.ai/code/session_01NpWWjywQsozhFp7pgsz1Cy
Summary by CodeRabbit