ci: use bash shell for all os at install desktop dependencies step#280
ci: use bash shell for all os at install desktop dependencies step#280
Conversation
Signed-off-by: Samuel K <skevetter@pm.me>
📝 WalkthroughWalkthroughUpdates the GitHub Actions release workflow to run the desktop install step with bash, add Flatpak preparation (copying assets, computing SHA256, restoring/preparing manifests), switch several release/upload steps to draft/prerelease flags, and introduce a gated prerelease job emitting draft and prerelease workflow paths. Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub as GitHub Events
participant Workflow as release.yml
participant Builder as Desktop Build Steps
participant Flatpak as Flatpak Prep Steps
participant Tauri as Tauri Release Action
participant Upload as Artifact Upload
GitHub->>Workflow: release/tag trigger
Workflow->>Builder: install desktop deps (shell: bash)
Builder->>Flatpak: copy assets, compute SHA256, prepare manifest
Flatpak->>Workflow: prepared Flatpak artifacts & manifest
Workflow->>Tauri: run tauri release (releaseDraft/prerelease flags)
Tauri->>Upload: produce artifacts
Upload->>Workflow: upload artifacts (draft/prerelease flags)
Workflow->>GitHub: conditional prerelease job runs if release.prerelease
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 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 |
There was a problem hiding this comment.
Pull request overview
This PR enhances the GitHub Actions release workflow by adding cross-platform consistency and improving release handling logic. While the title focuses on the shell specification change, the PR also introduces dynamic release configuration based on the triggering event.
Changes:
- Add explicit bash shell specification to the "install desktop dependencies" step for consistency across all operating systems (Linux, macOS, Windows)
- Replace hardcoded
prerelease: truewith conditional logic that sets it based on the event type - Add
releaseDraftconfiguration to create draft releases for manual workflow dispatches
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/release.yml:
- Around line 176-177: The PR introduces conditional release behavior using the
expressions involving github.event_name and the variables prerelease and
releaseDraft (prerelease: ${{ github.event_name == 'release' && 'true' ||
'false' }} and releaseDraft: ${{ github.event_name != 'release' && 'true' ||
'false' }}), which is not mentioned in the PR description; update the PR
title/description to explicitly state this behavioral change (how prerelease and
releaseDraft are now derived from github.event_name), why it matters, and any
expected downstream effects or migration notes so reviewers can assess the
impact.
- Around line 176-177: The softprops upload steps are hardcoding prerelease:
true which conflicts with the tauri action's conditional prerelease/releaseDraft
settings; update the softprops steps to use the same conditional expression used
by the tauri action for prerelease (e.g. set prerelease to ${{ github.event_name
== 'release' && 'true' || 'false' }}) or explicitly set draft to the same
releaseDraft expression (e.g. draft: ${{ github.event_name != 'release' &&
'true' || 'false' }}) so both the tauri action and the softprops uploads produce
a consistent draft/prerelease state.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/release.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Build CLI Binary on ubuntu-latest
- GitHub Check: Build CLI Binary on windows-latest
- GitHub Check: Build CLI Binary on macos-latest
- GitHub Check: Lint
🔇 Additional comments (1)
.github/workflows/release.yml (1)
161-161: LGTM! Explicit shell ensures cross-platform consistency.Adding
shell: bashensures the step runs consistently across all operating systems, including Windows (which would otherwise default to PowerShell). This aligns with the PR objective.
Signed-off-by: Samuel K <skevetter@pm.me>
Signed-off-by: Samuel K <skevetter@pm.me>
Signed-off-by: Samuel K <skevetter@pm.me>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/release.yml:
- Around line 258-262: The workflow step "restore flatpak manifest for build"
currently removes the whole "$GITHUB_WORKSPACE/desktop/flatpak/" directory but
only moves back sh.loft.devpod.yml, leaving DevPod.desktop and
DevPod.metainfo.xml missing and breaking the subsequent "prepare flatpak
manifest for build" step; change the step to restore the full directory (e.g.,
mv "$GITHUB_WORKSPACE/desktop/flatpak-build"/*
"$GITHUB_WORKSPACE/desktop/flatpak/" or cp -r
"$GITHUB_WORKSPACE/desktop/flatpak-build/."
"$GITHUB_WORKSPACE/desktop/flatpak/") so that sh.loft.devpod.yml plus
DevPod.desktop and DevPod.metainfo.xml are present for the Flatpak build.
- Around line 294-303: The prerelease publishing step using
softprops/action-gh-release@v2 currently sets tag_name and prerelease but does
not unset the draft flag, so add the input draft: false to the action invocation
(the step that uses softprops/action-gh-release@v2 and provides tag_name and
prerelease) so the job will undraft the release when updating it.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/release.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Build CLI Binary on macos-latest
- GitHub Check: Build CLI Binary on windows-latest
- GitHub Check: Build CLI Binary on ubuntu-latest
- GitHub Check: Build CLI Binary on ubuntu-latest
- GitHub Check: Build CLI Binary on macos-latest
- GitHub Check: Build CLI Binary on windows-latest
- GitHub Check: Lint
🔇 Additional comments (8)
.github/workflows/release.yml (8)
160-161: LGTM! Consistent shell specification across all OS.Adding explicit
shell: bashensures consistent behavior across all platforms and aligns with the PR objective.
186-193: LGTM! Draft release strategy.Changing to
draft: truealigns with the new workflow strategy where releases are created as drafts first, then conditionally published by the prerelease job.
230-234: LGTM! Backup step before modifications.Creating a backup of flatpak files before SHA256 modifications is a good practice for later restoration during the local build preparation.
236-238: LGTM! Consistent shell specification.Adding explicit
shell: bashmaintains consistency across the workflow.
264-277: LGTM! Manifest preparation logic is sound.The step correctly transforms the manifest from URL-based references to local file paths and removes unnecessary SHA256 checksums for local builds. The use of
GITHUB_WORKSPACEis appropriate for the container context.Note: This step depends on the files restored in the previous step, which currently has an issue that needs to be addressed.
248-256: LGTM! Consistent draft release strategy.Both upload steps now use
draft: true, maintaining consistency with the new workflow where all assets are uploaded to a draft release before conditional publication.Also applies to: 285-292
2-5: Verify the workflow behavior for theprereleasedtrigger.The workflow triggers on
release.prereleased, meaning it runs after a prerelease is manually created. However, all build steps usedraft: truewhen uploading assets. Please verify:
- When the workflow is triggered by an existing prerelease event, do the
draft: trueparameters convert the prerelease back to a draft?- Does the final prerelease job successfully republish it as a prerelease?
- Is this the intended behavior, or should the draft parameters be conditional based on the trigger type?
For the
workflow_dispatchpath, the current logic makes sense (create draft, don't publish).
176-176: ThereleaseDraft: trueparameter is valid and correctly supported by tauri-apps/tauri-action@v0.6. No changes needed.
Signed-off-by: Samuel K <skevetter@pm.me>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
.github/workflows/release.yml (3)
186-194: Uploading CLI assets asdraft: truemay not matchrelease.prereleasedtriggering.If this workflow is only kicked off after the prerelease is published (Line 4), these uploads will target a draft release state; please confirm you’re intentionally flipping states later (and that it won’t cause an event loop).
230-257: Bug:VERSIONis undefined in “prepare flatpak assets”.
VERSIONis referenced in the sed replacements (Line 243), but it’s not set in that step (environment variables from prior steps won’t carry over). This will produce wrong manifests/assets.Proposed fix
- name: prepare flatpak assets shell: bash run: | + set -euo pipefail + VERSION="${{ inputs.tag || github.ref_name }}" + VERSION="${VERSION#v}" + DEB_SHA256=$(sha256sum /tmp/devpod/DevPod_*_amd64.deb | cut -d' ' -f1) META_SHA256=$(sha256sum ./desktop/flatpak/DevPod.metainfo.xml | cut -d' ' -f1) DESKTOP_SHA256=$(sha256sum ./desktop/flatpak/DevPod.desktop | cut -d' ' -f1) sed -i "s/\${VERSION}/${VERSION}/g" ./desktop/flatpak/sh.loft.devpod.yml sed -i "s/\${SHA256}/${DEB_SHA256}/g" ./desktop/flatpak/sh.loft.devpod.yml sed -i "s/\${DESKTOP_SHA256}/${DESKTOP_SHA256}/g" ./desktop/flatpak/sh.loft.devpod.yml sed -i "s/\${META_SHA256}/${META_SHA256}/g" ./desktop/flatpak/sh.loft.devpod.yml
169-184:releaseDraft: trueis incompatible with therelease: types: [prereleased]trigger and will cause the workflow to fail.The workflow is triggered when a release is created as a prerelease. At that point, the GitHub Release exists with
draft=false(prerelease ≠ draft). However, the tauri-action is configured withreleaseDraft: true. According to the tauri-action documentation, when a release already exists for the giventagName, thereleaseDraftvalue must match the existing release's draft status. This mismatch will cause the action to fail.Either change
releaseDrafttofalseto match the prerelease release state, or adjust the workflow trigger/logic if draft releases are intended.
🤖 Fix all issues with AI agents
In @.github/workflows/release.yml:
- Around line 294-304: The prerelease job's gating using "if:
github.event.release.prerelease" is unreliable for workflow_dispatch and may be
redundant for release: prereleased; change the condition on the "prerelease" job
to explicitly check the event name and any dispatch input (e.g., test
github.event_name == 'release' && github.event.action == 'prereleased' or use a
custom input like inputs.publish_prerelease) and/or add a boolean workflow input
to drive publishing, updating the "prerelease" job's if expression to reference
that input and the event name instead of relying solely on
github.event.release.prerelease.
🧹 Nitpick comments (2)
.github/workflows/release.yml (2)
160-168: Good change forcing bash here, but consider failing fast on errors.Since this now runs on all OSes via bash, consider
set -euo pipefailso failures don’t get masked (especially in versioning).
258-277: The “copy/restore” pattern makes sense, but the sed-based YAML edits are brittle.If the manifest format/indentation changes, the exact-match
sedreplacements can silently stop applying. Consider using a YAML-aware tool (e.g.,yq) or at least add a quick post-edit assertion (e.g.,rg/grepexpected lines) so failures are obvious.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/release.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Build CLI Binary on ubuntu-latest
- GitHub Check: Build CLI Binary on windows-latest
- GitHub Check: Build CLI Binary on macos-latest
- GitHub Check: Build CLI Binary on windows-latest
- GitHub Check: Lint
- GitHub Check: Build CLI Binary on ubuntu-latest
- GitHub Check: Build CLI Binary on macos-latest
🔇 Additional comments (2)
.github/workflows/release.yml (2)
285-293: LGTM: draft upload for flatpak bundle (assuming release flow is intentional).
23-28: All action versions referenced in the workflow are valid and exist as releases on GitHub Actions official repositories. No changes required.
Signed-off-by: Samuel K skevetter@pm.me
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.