Conversation
add a workflow to cut a Kortex release Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Florent Benoit <fbenoit@redhat.com>
benoitf
requested review from
bmahabirbu and
gastoner
and removed request for
a team
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
📝 WalkthroughWalkthroughIntroduces a new manually-triggered GitHub Actions workflow for releasing the application. The workflow updates version strings across configuration files, builds platform-specific artifacts (Windows, Ubuntu, macOS), creates and publishes release tags, and generates pnpm cache archives for distribution. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yaml:
- Around line 105-129: The version-bump PR creation currently runs inside the
tag job (the step named "Create the PR to bump the version in the main branch")
which can run before downstream matrix legs finish; move this entire script into
a new post-release job (e.g., "post_release_bump") that has needs: release and
an if condition requiring needs.release.result == 'success' &&
github.event.inputs.branch == 'main' so the bump only happens after a successful
release; ensure steps.TAG_UTIL.outputs.kortexVersion is made available to the
new job (either by calling TAG_UTIL again or by exposing the value as a workflow
output) and keep the same git/sed/gh commands and branch naming logic when
copying the step into the new job.
- Around line 91-94: The workflow only pushes the tag (git tag ...; git push
origin <tag>) so the release commit never gets pushed back to the source branch;
update the step that runs git commit and tagging to also push the commit to the
branch (for example run git push origin HEAD:${{ github.ref_name }} or git push
origin HEAD:${{ github.ref }}), gated so it doesn't push to main if you don't
want that, so that updated files (package.json, .flatpak-appdata.xml,
.github/ISSUE_TEMPLATE/bug_report.yml) live on the branch as well as the tag.
- Around line 73-80: The rotation is off-by-one: currentVersionItem and the
delete/insert positions target the line immediately above "next (development
version)" (which is `options:`) instead of the previous release entry. Update
the three places that use "$(expr ${nextVersionLineNumber} - 1)" for
reading/deleting/inserting the release item to "$(expr ${nextVersionLineNumber}
- 2)" (i.e., change currentVersionItem and the deletion/first insert to use -2),
and change the final insert which currently uses "$(expr
${nextVersionLineNumber} + 1)" to "$(expr ${nextVersionLineNumber} - 1)" so the
newVersionItem and currentVersionItem end up in the correct order; references:
nextVersionLineNumber, currentVersionItem, newVersionItem and the three sed
lines.
- Around line 26-29: The workflow currently accepts a free-text input named
"branch" and checks it out (the checkout step), while release secrets (e.g.,
KORTEX_BOT_TOKEN, Apple notarization, Azure Key Vault, Segment key) remain
available to run, allowing an attacker to trigger releases from arbitrary
branches; add an early validation step that hard-fails unless the input "branch"
matches an explicit allow-list (for example: main, production, or a tag pattern
like v* or refs/tags/v*), or remove the "branch" input entirely and dispatch
only from a fixed branch; implement this by adding a small run step before
checkout that inspects inputs.branch or github.ref and exits non-zero if it does
not match the allowed values so the job never reaches the checkout or
secret-using steps (and update any dispatch logic accordingly).
🪄 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
Run ID: 46fff509-cb4f-4b6a-9a8a-2552c7062b68
📒 Files selected for processing (1)
.github/workflows/release.yaml
| branch: | ||
| description: 'Branch to use for the release' | ||
| required: true | ||
| default: main |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions workflow_dispatch who can trigger it, and are repository secrets available if the workflow checks out and executes code from another branch via actions/checkout ref?
💡 Result:
Who can trigger workflow_dispatch: Users with write access to the repository can trigger it manually via the GitHub UI (Actions tab), GitHub CLI, or REST API. The workflow file must be present on the default branch. Repository secrets availability: Yes, repository secrets are available in workflow_dispatch triggered workflows, regardless of whether actions/checkout uses a different ref/branch. Secrets are provided to the runner based on the repository and trigger event, not the checked-out code/branch. The checkout with ref only changes the working directory files and git context (e.g., GITHUB_SHA), but secrets like ${{ secrets.MY_SECRET }} remain accessible throughout the job steps.
Citations:
- 1: https://docs.github.com/actions/using-workflows/triggering-a-workflow
- 2: https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow
- 3: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions?tool=cli
- 4: https://docs.github.com/actions/security-guides/using-secrets-in-github-actions
- 5: https://github.com/actions/checkout
- 6: https://github.com/actions/checkout/blob/main/README.md
Restrict the release branch to prevent unreviewed code from being signed and published with release secrets.
The branch input accepts free-text input (lines 26–29), which is then checked out at line 50–53. However, repository secrets (KORTEX_BOT_TOKEN, Apple notarization, Azure Key Vault, Segment key) remain available throughout the workflow regardless of which branch is checked out (lines 147–205). This means a user with write access can trigger the workflow with an arbitrary unreviewed branch and publish it using production release secrets.
Instead, hard-fail unless branch matches an explicit allow-list (e.g., main, production or a semver tag pattern), or remove the input and dispatch from a fixed release branch only.
Applies to: lines 26–29, 50–53, 147–149, 165–205
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml around lines 26 - 29, The workflow currently
accepts a free-text input named "branch" and checks it out (the checkout step),
while release secrets (e.g., KORTEX_BOT_TOKEN, Apple notarization, Azure Key
Vault, Segment key) remain available to run, allowing an attacker to trigger
releases from arbitrary branches; add an early validation step that hard-fails
unless the input "branch" matches an explicit allow-list (for example: main,
production, or a tag pattern like v* or refs/tags/v*), or remove the "branch"
input entirely and dispatch only from a fixed branch; implement this by adding a
small run step before checkout that inspects inputs.branch or github.ref and
exits non-zero if it does not match the allowed values so the job never reaches
the checkout or secret-using steps (and update any dispatch logic accordingly).
| nextVersionLineNumber=$(grep -n "next (development version)" .github/ISSUE_TEMPLATE/bug_report.yml | cut -d ":" -f 1 | head -n 1) | ||
| currentVersionItem=$(sed "$(expr ${nextVersionLineNumber} - 1)q;d" .github/ISSUE_TEMPLATE/bug_report.yml) | ||
| newVersionItem=$(echo "$currentVersionItem" | sed -r -e "s|\".*\"|\"${{ steps.TAG_UTIL.outputs.kortexVersion }}\"|") | ||
| # delete the lines before the next version line | ||
| sed -i "$(expr ${nextVersionLineNumber} - 1)d" .github/ISSUE_TEMPLATE/bug_report.yml | ||
| # insert the version being tagged | ||
| sed -i "$(expr ${nextVersionLineNumber} - 1)i\\${newVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml | ||
| sed -i "$(expr ${nextVersionLineNumber} + 1)i\\${currentVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml |
There was a problem hiding this comment.
Fix the off-by-one when rotating the bug-report versions.
Line 74 currently reads the line above next (development version). In the current .github/ISSUE_TEMPLATE/bug_report.yml, that line is options:, so this block duplicates options: and breaks the YAML instead of moving the previous release entry.
🐛 Possible fix
- currentVersionItem=$(sed "$(expr ${nextVersionLineNumber} - 1)q;d" .github/ISSUE_TEMPLATE/bug_report.yml)
+ currentVersionItem=$(sed "$((nextVersionLineNumber + 1))q;d" .github/ISSUE_TEMPLATE/bug_report.yml)
newVersionItem=$(echo "$currentVersionItem" | sed -r -e "s|\".*\"|\"${{ steps.TAG_UTIL.outputs.kortexVersion }}\"|")
- # delete the lines before the next version line
- sed -i "$(expr ${nextVersionLineNumber} - 1)d" .github/ISSUE_TEMPLATE/bug_report.yml
- # insert the version being tagged
- sed -i "$(expr ${nextVersionLineNumber} - 1)i\\${newVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml
- sed -i "$(expr ${nextVersionLineNumber} + 1)i\\${currentVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml
+ sed -i "$((nextVersionLineNumber + 1))d" .github/ISSUE_TEMPLATE/bug_report.yml
+ sed -i "${nextVersionLineNumber}i\\${newVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml
+ sed -i "$((nextVersionLineNumber + 2))i\\${currentVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| nextVersionLineNumber=$(grep -n "next (development version)" .github/ISSUE_TEMPLATE/bug_report.yml | cut -d ":" -f 1 | head -n 1) | |
| currentVersionItem=$(sed "$(expr ${nextVersionLineNumber} - 1)q;d" .github/ISSUE_TEMPLATE/bug_report.yml) | |
| newVersionItem=$(echo "$currentVersionItem" | sed -r -e "s|\".*\"|\"${{ steps.TAG_UTIL.outputs.kortexVersion }}\"|") | |
| # delete the lines before the next version line | |
| sed -i "$(expr ${nextVersionLineNumber} - 1)d" .github/ISSUE_TEMPLATE/bug_report.yml | |
| # insert the version being tagged | |
| sed -i "$(expr ${nextVersionLineNumber} - 1)i\\${newVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml | |
| sed -i "$(expr ${nextVersionLineNumber} + 1)i\\${currentVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml | |
| nextVersionLineNumber=$(grep -n "next (development version)" .github/ISSUE_TEMPLATE/bug_report.yml | cut -d ":" -f 1 | head -n 1) | |
| currentVersionItem=$(sed "$((nextVersionLineNumber + 1))q;d" .github/ISSUE_TEMPLATE/bug_report.yml) | |
| newVersionItem=$(echo "$currentVersionItem" | sed -r -e "s|\".*\"|\"${{ steps.TAG_UTIL.outputs.kortexVersion }}\"|") | |
| sed -i "$((nextVersionLineNumber + 1))d" .github/ISSUE_TEMPLATE/bug_report.yml | |
| sed -i "${nextVersionLineNumber}i\\${newVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml | |
| sed -i "$((nextVersionLineNumber + 2))i\\${currentVersionItem}" .github/ISSUE_TEMPLATE/bug_report.yml |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml around lines 73 - 80, The rotation is
off-by-one: currentVersionItem and the delete/insert positions target the line
immediately above "next (development version)" (which is `options:`) instead of
the previous release entry. Update the three places that use "$(expr
${nextVersionLineNumber} - 1)" for reading/deleting/inserting the release item
to "$(expr ${nextVersionLineNumber} - 2)" (i.e., change currentVersionItem and
the deletion/first insert to use -2), and change the final insert which
currently uses "$(expr ${nextVersionLineNumber} + 1)" to "$(expr
${nextVersionLineNumber} - 1)" so the newVersionItem and currentVersionItem end
up in the correct order; references: nextVersionLineNumber, currentVersionItem,
newVersionItem and the three sed lines.
| git commit -m "chore: 🥁 tagging ${{ steps.TAG_UTIL.outputs.githubTag }} 🥳" | ||
| echo "Tagging with ${{ steps.TAG_UTIL.outputs.githubTag }}" | ||
| git tag ${{ steps.TAG_UTIL.outputs.githubTag }} | ||
| git push origin ${{ steps.TAG_UTIL.outputs.githubTag }} |
There was a problem hiding this comment.
If you keep non-main releases, push the release commit back to that branch.
Only the tag is pushed here. For any non-main run, the updated package.json, .flatpak-appdata.xml, and .github/ISSUE_TEMPLATE/bug_report.yml live only on the tagged commit, so the next release from that branch starts from stale metadata unless someone manually fast-forwards it.
🐛 Possible fix
git commit -m "chore: 🥁 tagging ${{ steps.TAG_UTIL.outputs.githubTag }} 🥳"
echo "Tagging with ${{ steps.TAG_UTIL.outputs.githubTag }}"
git tag ${{ steps.TAG_UTIL.outputs.githubTag }}
+ if [ "${{ github.event.inputs.branch }}" != "main" ]; then
+ git push origin HEAD:${{ github.event.inputs.branch }}
+ fi
git push origin ${{ steps.TAG_UTIL.outputs.githubTag }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| git commit -m "chore: 🥁 tagging ${{ steps.TAG_UTIL.outputs.githubTag }} 🥳" | |
| echo "Tagging with ${{ steps.TAG_UTIL.outputs.githubTag }}" | |
| git tag ${{ steps.TAG_UTIL.outputs.githubTag }} | |
| git push origin ${{ steps.TAG_UTIL.outputs.githubTag }} | |
| git commit -m "chore: 🥁 tagging ${{ steps.TAG_UTIL.outputs.githubTag }} 🥳" | |
| echo "Tagging with ${{ steps.TAG_UTIL.outputs.githubTag }}" | |
| git tag ${{ steps.TAG_UTIL.outputs.githubTag }} | |
| if [ "${{ github.event.inputs.branch }}" != "main" ]; then | |
| git push origin HEAD:${{ github.event.inputs.branch }} | |
| fi | |
| git push origin ${{ steps.TAG_UTIL.outputs.githubTag }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml around lines 91 - 94, The workflow only
pushes the tag (git tag ...; git push origin <tag>) so the release commit never
gets pushed back to the source branch; update the step that runs git commit and
tagging to also push the commit to the branch (for example run git push origin
HEAD:${{ github.ref_name }} or git push origin HEAD:${{ github.ref }}), gated so
it doesn't push to main if you don't want that, so that updated files
(package.json, .flatpak-appdata.xml, .github/ISSUE_TEMPLATE/bug_report.yml) live
on the branch as well as the tag.
| - name: Create the PR to bump the version in the main branch (only if we're tagging from main branch) | ||
| if: ${{ github.event.inputs.branch == 'main' }} | ||
| run: | | ||
| git config --local user.name ${{ github.actor }} | ||
| git config --local user.email "${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com" | ||
| CURRENT_VERSION=$(echo "${{ steps.TAG_UTIL.outputs.kortexVersion }}") | ||
| tmp=${CURRENT_VERSION%.*} | ||
| minor=${tmp#*.} | ||
| bumpedVersion=${CURRENT_VERSION%%.*}.$((minor + 1)).0 | ||
| bumpedBranchName="bump-to-${bumpedVersion}" | ||
| git checkout -b "${bumpedBranchName}" | ||
| sed -i "s#version\":\ \"\(.*\)\",#version\":\ \"${bumpedVersion}-next\",#g" package.json | ||
| find extensions/* -maxdepth 3 -name "package.json" | xargs -I {} sed -i "s#version\":\ \"\(.*\)\",#version\":\ \"${bumpedVersion}-next\",#g" {} | ||
| find packages/* -maxdepth 1 -name "package.json" | xargs -I {} sed -i "s#version\":\ \"\(.*\)\",#version\":\ \"${bumpedVersion}-next\",#g" {} | ||
| git add package.json extensions/*/package.json extensions/*/packages/*/package.json packages/*/package.json | ||
|
|
||
| git commit -s --amend -m "chore: bump version to ${bumpedVersion}" | ||
| git push origin "${bumpedBranchName}" | ||
| echo -e "📢 Bump version to ${bumpedVersion}\n\n${{ steps.TAG_UTIL.outputs.kortexVersion }} has been released.\n\n Time to switch to the new ${bumpedVersion} version 🥳" > /tmp/pr-title | ||
| pullRequestUrl=$(gh pr create --title "chore: 📢 Bump version to ${bumpedVersion}" --body-file /tmp/pr-title --head "${bumpedBranchName}" --base "main") | ||
| echo "📢 Pull request created: ${pullRequestUrl}" | ||
| echo "➡️ Flag the PR as being ready for review" | ||
| gh pr ready "${pullRequestUrl}" | ||
| echo "🔅 Mark the PR as being ok to be merged automatically" | ||
| gh pr merge "${pullRequestUrl}" --auto --rebase |
There was a problem hiding this comment.
Gate the version-bump PR on a successful release.
This block runs inside tag, before build and release. If a later matrix leg fails, main is already bumped and the repo metadata now references a release that never shipped. Move it to a separate post-release job that depends on release.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml around lines 105 - 129, The version-bump PR
creation currently runs inside the tag job (the step named "Create the PR to
bump the version in the main branch") which can run before downstream matrix
legs finish; move this entire script into a new post-release job (e.g.,
"post_release_bump") that has needs: release and an if condition requiring
needs.release.result == 'success' && github.event.inputs.branch == 'main' so the
bump only happens after a successful release; ensure
steps.TAG_UTIL.outputs.kortexVersion is made available to the new job (either by
calling TAG_UTIL again or by exposing the value as a workflow output) and keep
the same git/sed/gh commands and branch naming logic when copying the step into
the new job.
1 participant
add a workflow to cut a Kortex release