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! |
📝 WalkthroughWalkthroughAdds a new manually-triggered GitHub Actions workflow ( Changes
Sequence Diagram(s)mermaid 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.
.github/workflows/release.yaml
Outdated
| @@ -0,0 +1,254 @@ | |||
| # | |||
| # Copyright (C) 2022-2025 Red Hat, Inc. | |||
Signed-off-by: Florent BENOIT <fbenoit@redhat.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/release.yaml (2)
165-167: Guard against empty telemetry key.If
SEGMENT_WRITE_KEYis unset or empty, this silently writes an empty string toproduct.json, which may cause telemetry to malfunction in production builds without a clear error. Consider failing fast if the secret is missing.♻️ Proposed guard
- name: setup telemetry key for production run: | + if [ -z "${{ secrets.SEGMENT_WRITE_KEY }}" ]; then + echo "::error::SEGMENT_WRITE_KEY secret is not set" + exit 1 + fi jq --arg key "${{ secrets.SEGMENT_WRITE_KEY }}" '.telemetry.key = $key' product.json > product.json.tmp && rm product.json && mv product.json.tmp product.json🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yaml around lines 165 - 167, The workflow step "setup telemetry key for production" currently writes SEGMENT_WRITE_KEY into product.json without checking for emptiness; update that step to guard and fail fast when the secret is missing by verifying ${{ secrets.SEGMENT_WRITE_KEY }} before running jq (e.g., add an if condition or a short shell check that exits non-zero with a clear message if the variable is empty) so the jq command that updates product.json only runs when SEGMENT_WRITE_KEY is present.
56-59: Consider validating the version input format.The
versioninput is used directly in shell commands and as a git tag. While Git will reject obviously invalid tag names, validating the format early provides a clearer error message and prevents potential issues with special characters in sed patterns.♻️ Proposed validation
- name: Generate tag utilities id: TAG_UTIL run: | + if ! [[ "${{ github.event.inputs.version }}" =~ ^[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$ ]]; then + echo "::error::Invalid version format. Expected semver (e.g., 1.2.3 or 1.2.3-beta.1)" + exit 1 + fi TAG_PATTERN=${{ github.event.inputs.version }} echo "githubTag=v$TAG_PATTERN" >> ${GITHUB_OUTPUT} echo "kortexVersion=$TAG_PATTERN" >> ${GITHUB_OUTPUT}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yaml around lines 56 - 59, Validate the incoming version input in the workflow before using it: after assigning TAG_PATTERN="${{ github.event.inputs.version }}", test it against a strict regex (e.g. semver-like such as ^[0-9]+\.[0-9]+\.[0-9]+(-[A-Za-z0-9.-]+)?$ or your chosen allowed pattern) and if it doesn't match, print a clear error to stderr and exit non-zero; if it matches, continue to set githubTag and kortexVersion into GITHUB_OUTPUT as before. Use the TAG_PATTERN variable name in your check and fail fast with an explanatory message so the subsequent echo "githubTag=v$TAG_PATTERN" >> ${GITHUB_OUTPUT} and echo "kortexVersion=$TAG_PATTERN" >> ${GITHUB_OUTPUT} only run with a validated value.
🤖 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:
- Line 121: The commit command currently rewrites history by using --amend;
replace that usage so the workflow creates a fresh commit instead. Locate the
line with git commit -s --amend -m "chore: bump version to ${bumpedVersion}" and
remove the --amend flag so the action runs git commit -s -m "chore: bump version
to ${bumpedVersion}" (ensuring the new commit is created rather than amending an
existing one).
- Line 243: The podman invocation uses interactive flags "-it" which allocate a
TTY not available in CI; update the podman run command (the line starting with
"podman run --platform linux/${{ matrix.arch }} ...") to remove the "-t" flag
(and remove "-i" as well for non-interactive CI runs) so it runs
non-interactively in the workflow.
---
Nitpick comments:
In @.github/workflows/release.yaml:
- Around line 165-167: The workflow step "setup telemetry key for production"
currently writes SEGMENT_WRITE_KEY into product.json without checking for
emptiness; update that step to guard and fail fast when the secret is missing by
verifying ${{ secrets.SEGMENT_WRITE_KEY }} before running jq (e.g., add an if
condition or a short shell check that exits non-zero with a clear message if the
variable is empty) so the jq command that updates product.json only runs when
SEGMENT_WRITE_KEY is present.
- Around line 56-59: Validate the incoming version input in the workflow before
using it: after assigning TAG_PATTERN="${{ github.event.inputs.version }}", test
it against a strict regex (e.g. semver-like such as
^[0-9]+\.[0-9]+\.[0-9]+(-[A-Za-z0-9.-]+)?$ or your chosen allowed pattern) and
if it doesn't match, print a clear error to stderr and exit non-zero; if it
matches, continue to set githubTag and kortexVersion into GITHUB_OUTPUT as
before. Use the TAG_PATTERN variable name in your check and fail fast with an
explanatory message so the subsequent echo "githubTag=v$TAG_PATTERN" >>
${GITHUB_OUTPUT} and echo "kortexVersion=$TAG_PATTERN" >> ${GITHUB_OUTPUT} only
run with a validated value.
🪄 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: 5bd6eaf3-4098-4d02-b17c-6f8d54dfcd7f
📒 Files selected for processing (1)
.github/workflows/release.yaml
| 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}" |
There was a problem hiding this comment.
Remove --amend flag – this should create a fresh commit, not rewrite history.
Using --amend here rewrites the tagged release commit with the version-bump changes. Although pushed to a new branch, this creates confusion: the PR shows a single commit that appears to be the release commit but with different content. The tag (githubTag) still points to the original commit SHA, but the branch head differs. Use a standard commit instead.
🐛 Proposed fix
- git commit -s --amend -m "chore: bump version to ${bumpedVersion}"
+ git commit -s -m "chore: bump version to ${bumpedVersion}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml at line 121, The commit command currently
rewrites history by using --amend; replace that usage so the workflow creates a
fresh commit instead. Locate the line with git commit -s --amend -m "chore: bump
version to ${bumpedVersion}" and remove the --amend flag so the action runs git
commit -s -m "chore: bump version to ${bumpedVersion}" (ensuring the new commit
is created rather than amending an existing one).
| uses: docker/setup-qemu-action@ce360397dd3f832beb865e1373c09c0e9f86d70a # v4.0.0 | ||
| - name: create the pnpm store from the dependencies | ||
| run: | | ||
| podman run --platform linux/${{ matrix.arch }} -v $(pwd):/project --rm -it --entrypoint=sh node:24 -c "cd /project && npm install -g corepack@latest && corepack enable pnpm && COREPACK_ENABLE_DOWNLOAD_PROMPT=0 pnpm install --frozen-lockfile --store-dir pnpm-store" |
There was a problem hiding this comment.
Remove -t flag from podman run – no TTY available in CI.
The -it flags allocate a pseudo-TTY (-t) and keep stdin open (-i). In GitHub Actions runners, no TTY is available, which can cause unexpected behavior or warnings. For non-interactive container execution, drop both flags or use only -i if stdin piping is needed.
🐛 Proposed fix
- podman run --platform linux/${{ matrix.arch }} -v $(pwd):/project --rm -it --entrypoint=sh node:24 -c "cd /project && npm install -g corepack@latest && corepack enable pnpm && COREPACK_ENABLE_DOWNLOAD_PROMPT=0 pnpm install --frozen-lockfile --store-dir pnpm-store"
+ podman run --platform linux/${{ matrix.arch }} -v $(pwd):/project --rm --entrypoint=sh node:24 -c "cd /project && npm install -g corepack@latest && corepack enable pnpm && COREPACK_ENABLE_DOWNLOAD_PROMPT=0 pnpm install --frozen-lockfile --store-dir pnpm-store"📝 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.
| podman run --platform linux/${{ matrix.arch }} -v $(pwd):/project --rm -it --entrypoint=sh node:24 -c "cd /project && npm install -g corepack@latest && corepack enable pnpm && COREPACK_ENABLE_DOWNLOAD_PROMPT=0 pnpm install --frozen-lockfile --store-dir pnpm-store" | |
| podman run --platform linux/${{ matrix.arch }} -v $(pwd):/project --rm --entrypoint=sh node:24 -c "cd /project && npm install -g corepack@latest && corepack enable pnpm && COREPACK_ENABLE_DOWNLOAD_PROMPT=0 pnpm install --frozen-lockfile --store-dir pnpm-store" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yaml at line 243, The podman invocation uses
interactive flags "-it" which allocate a TTY not available in CI; update the
podman run command (the line starting with "podman run --platform linux/${{
matrix.arch }} ...") to remove the "-t" flag (and remove "-i" as well for
non-interactive CI runs) so it runs non-interactively in the workflow.
2 participants
add a workflow to cut a Kortex release