Build RedDB sidecar from pinned source when needed - #100
Conversation
|
Warning Review limit reached
More reviews will be available in 52 minutes and 58 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughRelease workflows and the RedDB sync helper now accept an optional source ref. When it is set, the jobs resolve the commit, check out ChangesRedDB source-ref release path
Sequence Diagram(s)sequenceDiagram
participant Workflow as GitHub Actions workflow
participant Check as scripts/check-reddb-release-assets.mjs
participant GitHubAPI as GitHub API
participant Checkout as RedDB source checkout step
participant Sync as scripts/sync-reddb.mjs
participant Cargo as cargo
Workflow->>Check: run preflight with REDDB_SOURCE_REF
Check->>GitHubAPI: resolve source commit SHA
GitHubAPI-->>Check: commit lookup result
Check-->>Workflow: exit(0) when source build is enabled
Workflow->>Checkout: checkout reddb-io/reddb at REDDB_SOURCE_REF
Workflow->>Sync: pnpm reddb:sync
Sync->>Cargo: cargo build --message-format=json
Cargo-->>Sync: compiler-artifact JSON
Sync-->>Workflow: copy red-${triple}${ext} to sidecar path
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release-fast.yml:
- Around line 60-73: The release workflow adds new third-party action references
by tag, which should be pinned to immutable commit SHAs. Update the actions used
in the Checkout RedDB source step and the Rust cache step to specific commit
hashes instead of version tags, and keep the existing workflow structure and
behavior unchanged.
- Around line 10-13: The release workflow input for reddb_source_ref is allowed
to be a branch or tag, but the checkout step still uses the raw value and can
build a different RedDB revision than the validation step resolved. Update the
workflow so the job only accepts or propagates the resolved full SHA from
check-reddb-release-assets.mjs, and ensure the checkout/build path uses that
resolved commit instead of the original input. Use the reddb_source_ref input
and the check-reddb-release-assets.mjs resolution flow as the key symbols to
locate the affected logic.
In @.github/workflows/release.yml:
- Around line 155-168: The release workflow currently adds new third-party
actions by tag, which should be pinned to immutable commit SHAs. Update the
Checkout RedDB source step using actions/checkout and the cache step using
swatinem/rust-cache so both references are locked to specific commit hashes
rather than version tags, keeping the existing step names and configuration
intact.
In `@scripts/sync-reddb.mjs`:
- Around line 122-128: The version fallback in sync-reddb.mjs is too broad
because sh(dest, ["version"]) failures are being ignored unconditionally. Update
the builtVersion logic to check whether the target triple matches the host
triple before suppressing the error, and only use the red built for ${triple}
fallback for true cross-builds. If the target and host match, rethrow the
version error so native release-matrix builds do not silently package a broken
sidecar. Use the existing triple and dest version flow to locate the change.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a18ee864-ff94-4409-8126-75d150745175
📒 Files selected for processing (4)
.github/workflows/release-fast.yml.github/workflows/release.ymlscripts/check-reddb-release-assets.mjsscripts/sync-reddb.mjs
| reddb_source_ref: | ||
| description: "Optional RedDB source commit/ref to build instead of downloading release assets" | ||
| required: false | ||
| default: "" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Require REDDB_SOURCE_REF to be a full SHA.
check-reddb-release-assets.mjs resolves the ref, but Line 65 still checks out the raw input. If someone passes a branch or movable tag, this job can build a different RedDB revision than the one validation reported.
Suggested fix
+ - name: Validate pinned RedDB source ref
+ if: env.REDDB_SOURCE_REF != ''
+ shell: bash
+ run: |
+ [[ "${REDDB_SOURCE_REF}" =~ ^[0-9a-f]{40}$ ]] || {
+ echo "::error::REDDB_SOURCE_REF must be a full 40-character commit SHA"
+ exit 1
+ }
+
- name: Checkout RedDB source
if: env.REDDB_SOURCE_REF != ''
uses: actions/checkout@v7
with:
repository: reddb-io/reddb
ref: ${{ env.REDDB_SOURCE_REF }}Also applies to: 24-24, 60-67
🤖 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-fast.yml around lines 10 - 13, The release
workflow input for reddb_source_ref is allowed to be a branch or tag, but the
checkout step still uses the raw value and can build a different RedDB revision
than the validation step resolved. Update the workflow so the job only accepts
or propagates the resolved full SHA from check-reddb-release-assets.mjs, and
ensure the checkout/build path uses that resolved commit instead of the original
input. Use the reddb_source_ref input and the check-reddb-release-assets.mjs
resolution flow as the key symbols to locate the affected logic.
| - name: Checkout RedDB source | ||
| if: env.REDDB_SOURCE_REF != '' | ||
| uses: actions/checkout@v7 | ||
| with: | ||
| repository: reddb-io/reddb | ||
| ref: ${{ env.REDDB_SOURCE_REF }} | ||
| path: .red/tmp/reddb-source | ||
| persist-credentials: false | ||
|
|
||
| - uses: swatinem/rust-cache@v2 | ||
| with: | ||
| workspaces: "apps/desktop/src-tauri -> target" | ||
| workspaces: | | ||
| apps/desktop/src-tauri -> target | ||
| .red/tmp/reddb-source -> target |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Pin the added workflow actions to commit SHAs.
Line 62 and Line 69 introduce new action references by tag. That violates the blanket policy from zizmor and leaves the release path open to upstream tag retargeting.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 62-62: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 69-69: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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-fast.yml around lines 60 - 73, The release
workflow adds new third-party action references by tag, which should be pinned
to immutable commit SHAs. Update the actions used in the Checkout RedDB source
step and the Rust cache step to specific commit hashes instead of version tags,
and keep the existing workflow structure and behavior unchanged.
Source: Linters/SAST tools
| - name: Checkout RedDB source | ||
| if: env.REDDB_SOURCE_REF != '' | ||
| uses: actions/checkout@v7 | ||
| with: | ||
| repository: reddb-io/reddb | ||
| ref: ${{ env.REDDB_SOURCE_REF }} | ||
| path: .red/tmp/reddb-source | ||
| persist-credentials: false | ||
|
|
||
| - uses: swatinem/rust-cache@v2 | ||
| with: | ||
| workspaces: "apps/desktop/src-tauri -> target" | ||
| workspaces: | | ||
| apps/desktop/src-tauri -> target | ||
| .red/tmp/reddb-source -> target |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Pin the added workflow actions to commit SHAs.
Line 157 and Line 164 add new action refs by tag. That violates the blanket policy and weakens the release workflow against upstream tag retargeting.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 157-157: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 164-164: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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.yml around lines 155 - 168, The release workflow
currently adds new third-party actions by tag, which should be pinned to
immutable commit SHAs. Update the Checkout RedDB source step using
actions/checkout and the cache step using swatinem/rust-cache so both references
are locked to specific commit hashes rather than version tags, keeping the
existing step names and configuration intact.
Source: Linters/SAST tools
| let builtVersion = `red built for ${triple}`; | ||
| try { | ||
| builtVersion = sh(dest, ["version"]).trim(); | ||
| } catch { | ||
| // Cross-built binaries may not run on the build host; the release matrix builds native | ||
| // targets, so this is only a local-dev fallback. | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Only suppress version failures for actual cross-builds.
The release matrix builds native targets, so swallowing every dest version failure can package a broken sidecar. Compare the target with the host triple and rethrow when they match.
🐛 Proposed fix
+function rustHostTriple() {
+ const hostLine = sh("rustc", ["-vV"])
+ .split("\n")
+ .find((l) => l.startsWith("host:"));
+ return hostLine?.split(/\s+/)[1];
+}
+
// Target triple Tauri uses to resolve the sidecar (e.g. x86_64-unknown-linux-gnu).
// CI passes REDDB_TARGET from the release matrix; local dev falls back to the host.
function targetTriple() {
if (process.env.REDDB_TARGET) return process.env.REDDB_TARGET;
- const hostLine = sh("rustc", ["-vV"])
- .split("\n")
- .find((l) => l.startsWith("host:"));
- return hostLine?.split(/\s+/)[1];
+ return rustHostTriple();
}
const triple = targetTriple();
+const hostTriple = rustHostTriple(); let builtVersion = `red built for ${triple}`;
try {
builtVersion = sh(dest, ["version"]).trim();
-} catch {
+} catch (err) {
+ if (hostTriple === triple) throw err;
// Cross-built binaries may not run on the build host; the release matrix builds native
// targets, so this is only a local-dev fallback.
}📝 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.
| let builtVersion = `red built for ${triple}`; | |
| try { | |
| builtVersion = sh(dest, ["version"]).trim(); | |
| } catch { | |
| // Cross-built binaries may not run on the build host; the release matrix builds native | |
| // targets, so this is only a local-dev fallback. | |
| } | |
| let builtVersion = `red built for ${triple}`; | |
| try { | |
| builtVersion = sh(dest, ["version"]).trim(); | |
| } catch (err) { | |
| if (hostTriple === triple) throw err; | |
| // Cross-built binaries may not run on the build host; the release matrix builds native | |
| // targets, so this is only a local-dev fallback. | |
| } |
🤖 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 `@scripts/sync-reddb.mjs` around lines 122 - 128, The version fallback in
sync-reddb.mjs is too broad because sh(dest, ["version"]) failures are being
ignored unconditionally. Update the builtVersion logic to check whether the
target triple matches the host triple before suppressing the error, and only use
the red built for ${triple} fallback for true cross-builds. If the target and
host match, rethrow the version error so native release-matrix builds do not
silently package a broken sidecar. Use the existing triple and dest version flow
to locate the change.
1 participant
Summary
Validation
Note: a real local RedDB release build was attempted but blocked behind another long-running local cargo process in the RedDB workspace. The PR CI/release-fast path is the authoritative validation for the source-build workflow.
Need help on this PR? Tag
/codesmithwith what you need. Autofix is disabled.Summary by CodeRabbit
New Features
Bug Fixes