Sync from fork to update PR #840#852
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 28 minutes and 7 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (23)
📝 WalkthroughWalkthroughLarge migration from Yarn to pnpm across CI and scripts, plus extensive backend and frontend feature additions: Phase‑4 memory-tree retrieval/embedding, core→frontend CoreNotification bridge, provider_surfaces/respond-queue, webhook router/agent triggers, memory namespace API changes, many tests, new review tooling, and assorted UI copy and routing updates. Changes
Sequence Diagram(s)sequenceDiagram
rect rgba(200,200,255,0.5)
participant ExternalClient as External Client
end
rect rgba(200,255,200,0.5)
participant Router as Webhook Router / SocketManager
end
rect rgba(255,200,200,0.5)
participant Core as Core Triage / Runtime
end
rect rgba(255,255,200,0.5)
participant Agent as Agent Execution
end
rect rgba(200,255,255,0.5)
participant SocketIO as Socket.IO / Frontend Bridge
end
ExternalClient->>Router: POST /webhook (tunnel_uuid, body)
Router->>Router: lookup TunnelRegistration (by uuid)
alt target_kind == "echo"
Router-->>ExternalClient: 200 OK (echo response)
else target_kind == "agent"
Router-->>ExternalClient: 202 Accepted
Router->>Core: spawn triage (TriggerEnvelope) with 60s timeout
Core->>Agent: run triage pipeline / execute agent
Agent-->>Core: decision/result (or timeout)
Core->>SocketIO: publish "webhook:response" (decision payload)
else unknown
Router-->>ExternalClient: 501 Not Implemented
end
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
|
Current State Has some issues. Ie. No openhuman-core in .deb and state issues. Working on it now. |
|
for the script to work.. we'll need to also update the github actions to use |
Sure! Already on it. |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
docs/BUILDING.md (1)
11-41:⚠️ Potential issue | 🟡 MinorUpdate the existing build instructions to pnpm — they still reference yarn.
This PR migrates the monorepo to pnpm (new
pnpm-workspace.yaml, CI workflows,.husky/pre-push, etc.), but the "Prerequisites" and "Build from source" sections here still tell users to install and invokeyarn. That will leave contributors with a broken setup (yarn commands will either fail or fall back to different behavior vs. the pnpm lockfile used in CI).🛠️ Suggested fix
- `git` -- `node` + `yarn` +- `node` + `pnpm` - Rust toolchain (see `rust-toolchain.toml`) @@ # 2) Install JS deps (workspace) -yarn install +pnpm install @@ # 4) Stage core sidecar for the desktop app cd app -yarn core:stage +pnpm core:stage # 5) Build desktop app artifacts -yarn build +pnpm build @@ For local development instead of production build: ```bash -yarn dev +pnpm dev🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/BUILDING.md` around lines 11 - 41, The BUILDING.md instructions still reference yarn; update the Prerequisites and all example commands to use pnpm (e.g., replace "yarn install", "yarn core:stage", "yarn build", and "yarn dev" with the equivalent pnpm commands) and mention pnpm as a required tool alongside Node (referencing pnpm-workspace.yaml to signal the repo uses pnpm). Ensure the usage examples and CLI steps use pnpm consistently so local setup matches CI and the new lockfile behavior..github/workflows/e2e-agent-review.yml (1)
42-51:⚠️ Potential issue | 🔴 Critical
cache: "pnpm"insetup-nodewill fail because pnpm isn't installed yet (affects 5 workflows).
actions/setup-nodewithcache: pnpmrequires pnpm to be installed before the setup-node step runs. Here it runs aftersetup-node, so setup-node will fail withUnable to locate executable file: pnpm. The idiomatic fix is to install pnpm first viapnpm/action-setupand then runsetup-node.This issue occurs in:
.github/workflows/e2e-agent-review.yml(lines 42–51).github/workflows/build-windows.yml(lines 28–35).github/workflows/release.yml(lines 296–299).github/workflows/test.yml(lines 40–43).github/workflows/typecheck.yml(lines 30–33)🛠️ Suggested fix pattern (apply to all 5 workflows)
+ - name: Install pnpm + uses: pnpm/action-setup@v4 + with: + version: 10 + - name: Setup Node.js 24.x uses: actions/setup-node@v4 with: node-version: 24.x cache: "pnpm" - - - name: Install pnpm - run: npm install -g pnpmNote:
.github/workflows/build.ymlcorrectly installs pnpm first (line 56), then uses generic caching at lines 58–61, so it doesn't need changes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/e2e-agent-review.yml around lines 42 - 51, The "Setup Node.js 24.x" step uses with: cache: "pnpm" but pnpm is installed only after via the "Install pnpm" run step, causing setup-node to fail; fix by installing pnpm before calling actions/setup-node: replace the "Install pnpm" run step with the pnpm/action-setup action (or move the install to a prior step), then keep the "Setup Node.js 24.x" step with cache: "pnpm"; apply the same change to every workflow that currently defines a "Setup Node.js 24.x" step followed by an "Install pnpm" run step so pnpm exists when setup-node runs..github/workflows/release.yml (1)
292-299:⚠️ Potential issue | 🔴 CriticalInstall pnpm before running
setup-nodewithcache: pnpm— the current ordering will fail.
actions/setup-node@v4withcache: "pnpm"attempts to resolve the pnpm cache directory (viapnpm store path) during its own execution. This requires pnpm to already be onPATH, but the current workflow installs it afterward, causing the action to fail withpnpm: command not found.The fix is to use
pnpm/action-setup@v4beforesetup-node, which also respects thepackageManagerversion inpackage.json(currentlypnpm@10.10.0). Usingnpm install -g pnpmsilently ignores the pinned version and lets the CI environment drift from the repo declaration.This ordering issue exists in three files:
.github/workflows/release.yml(lines 292–299).github/workflows/test.yml(lines 37–43).github/workflows/typecheck.yml(lines 27–33)🔧 Proposed fix
+ - name: Install pnpm + uses: pnpm/action-setup@v4 + with: + version: 10.10.0 + - name: Setup Node.js 24.x uses: actions/setup-node@v4 with: node-version: 24.x cache: pnpm - - - name: Install pnpm - run: npm install -g pnpm🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 292 - 299, Move pnpm installation before setup-node and replace the global npm install with the official pnpm action: remove the "Install pnpm" step that runs "npm install -g pnpm" and instead add a step using "pnpm/action-setup@v4" configured to respect package.json packageManager (matching pnpm@10.10.0) before the "Setup Node.js 24.x" step (the steps named "Setup Node.js 24.x" and "Install pnpm" in the diff); apply this same change in the three workflows mentioned so actions/setup-node@v4 can successfully use cache: pnpm.
🧹 Nitpick comments (3)
docs/BUILDING.md (1)
103-116: Hashed CEF output directory in docs will go stale.
cef-dll-sys-06f9a023be70e68bis a Cargo build-script output hash — it will change whenever thecef-dll-sysdependency (or its build inputs) changes, silently breaking the documentedLD_LIBRARY_PATHfor future readers. Consider either (a) resolving the path at runtime with a glob, or (b) shipping a wrapper script in the repo that computes it.🛠️ More robust wrapper example
#!/bin/bash set -euo pipefail REL_DIR="/path/to/app/src-tauri/target/aarch64-unknown-linux-gnu/release" CEF_DIR="$(ls -d "$REL_DIR"/build/cef-dll-sys-*/out/cef_linux_aarch64 2>/dev/null | head -n1)" export LD_LIBRARY_PATH="$CEF_DIR:$REL_DIR/deps:$REL_DIR${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" exec "$REL_DIR/OpenHuman" --no-sandbox "$@"Also note: the hardcoded
0.52.28in the.debinstall example at Line 121 will drift fromversioninapp/src-tauri/tauri.conf.json; consider using a glob (OpenHuman_*_arm64.deb) instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/BUILDING.md` around lines 103 - 116, The docs hardcode a Cargo build-script hash in CEF_DIR which will break when the hash changes; update the wrapper script (the suggested ~/bin/openhuman or a repo-shipped script) to compute CEF_DIR at runtime using a glob like "$REL_DIR"/build/cef-dll-sys-*/out/cef_linux_aarch64 (or equivalent shell logic), ensure REL_DIR is set and export LD_LIBRARY_PATH by prepending that computed CEF_DIR and preserving any existing LD_LIBRARY_PATH, and replace the hardcoded .deb filename (version 0.52.28) with a glob such as OpenHuman_*_arm64.deb so the docs remain robust.package.json (1)
5-7: Redundant Yarn-styleworkspacesfield after migrating to pnpm.pnpm discovers workspace packages exclusively from
pnpm-workspace.yaml; thisworkspacesarray is a leftover from the Yarn setup and has no effect under pnpm. Safe to remove to avoid confusion and prevent other tools (or a straynpm/yarninvocation) from reading a potentially diverging workspace list.🧹 Proposed fix
"packageManager": "pnpm@10.10.0", - "workspaces": [ - "app" - ], "resolutions": { "@tauri-apps/api": "2.10.1" },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` around lines 5 - 7, Remove the redundant Yarn-style "workspaces" array from package.json (the top-level "workspaces" key shown in the diff) since pnpm uses pnpm-workspace.yaml to discover packages; delete that key/entry so the repository only relies on pnpm-workspace.yaml and avoid confusion from stale workspace configuration..github/workflows/test.yml (1)
45-57: Manualnode_modulescache is suboptimal for pnpm workspaces.This cache only stores the root
node_modules, but pnpm workspaces materialize dependencies in each package (e.g.,app/node_modules) as symlinks into a virtual store (node_modules/.pnpm). Depending on runner/filesystem, restoring symlinked trees viaactions/cachecan be lossy, and nothing here coversapp/node_modules.If you switch to
pnpm/action-setup(see the comment on lines 292-299 ofrelease.yml),actions/setup-node's built-incache: "pnpm"already caches pnpm's content-addressable store keyed onpnpm-lock.yaml— which is the idiomatic and more reliable approach. You can then drop this custom cache step entirely (or, if you keep anode_modulescache, includeapp/node_modulesinpath).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/test.yml around lines 45 - 57, The current custom cache step (id: pnpm-cache using actions/cache@v4) only caches root node_modules and can break pnpm workspaces; replace it by using pnpm/action-setup (or actions/setup-node with cache: "pnpm") so pnpm's content-addressable store is restored by keying on pnpm-lock.yaml, and remove the Install dependencies conditional on steps.pnpm-cache.outputs.cache-hit (or if you keep a manual cache, expand the cache path to include per-package dirs like app/node_modules and adjust uses: actions/cache accordingly). Ensure references to the pnpm-cache step or steps.pnpm-cache.outputs.cache-hit are removed or updated (e.g., in the "Install dependencies" step) when switching to pnpm/action-setup.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@app/package.json`:
- Line 26: The macos:dev npm script still invokes yarn; update the "macos:dev"
script (the value that currently contains "yarn macos:build:debug && open
'../target/debug/bundle/macos/OpenHuman.app'") to call pnpm instead (for example
use "pnpm run macos:build:debug && open
'../target/debug/bundle/macos/OpenHuman.app'") so the script works in the
pnpm-only environment and matches other package scripts.
In `@app/src-tauri/tauri.conf.json`:
- Around line 54-58: Populate the deb dependency fields so the generated .deb
and the control template declare runtime libs; set the JSON key
linux.deb.depends to an array listing needed packages (e.g., "libgtk-3-0",
"libwebkit2gtk-4.0-37", "libx11-6", "libgdk-pixbuf2.0-0", "libglib2.0-0") and
also add a matching Depends: line in the Debian control template (control.in)
that includes those packages (and keep ${shlibs:Depends}, ${misc:Depends} if
present) so both build paths require the same GTK/WebKit/X11 runtime packages at
install time.
---
Outside diff comments:
In @.github/workflows/e2e-agent-review.yml:
- Around line 42-51: The "Setup Node.js 24.x" step uses with: cache: "pnpm" but
pnpm is installed only after via the "Install pnpm" run step, causing setup-node
to fail; fix by installing pnpm before calling actions/setup-node: replace the
"Install pnpm" run step with the pnpm/action-setup action (or move the install
to a prior step), then keep the "Setup Node.js 24.x" step with cache: "pnpm";
apply the same change to every workflow that currently defines a "Setup Node.js
24.x" step followed by an "Install pnpm" run step so pnpm exists when setup-node
runs.
In @.github/workflows/release.yml:
- Around line 292-299: Move pnpm installation before setup-node and replace the
global npm install with the official pnpm action: remove the "Install pnpm" step
that runs "npm install -g pnpm" and instead add a step using
"pnpm/action-setup@v4" configured to respect package.json packageManager
(matching pnpm@10.10.0) before the "Setup Node.js 24.x" step (the steps named
"Setup Node.js 24.x" and "Install pnpm" in the diff); apply this same change in
the three workflows mentioned so actions/setup-node@v4 can successfully use
cache: pnpm.
In `@docs/BUILDING.md`:
- Around line 11-41: The BUILDING.md instructions still reference yarn; update
the Prerequisites and all example commands to use pnpm (e.g., replace "yarn
install", "yarn core:stage", "yarn build", and "yarn dev" with the equivalent
pnpm commands) and mention pnpm as a required tool alongside Node (referencing
pnpm-workspace.yaml to signal the repo uses pnpm). Ensure the usage examples and
CLI steps use pnpm consistently so local setup matches CI and the new lockfile
behavior.
---
Nitpick comments:
In @.github/workflows/test.yml:
- Around line 45-57: The current custom cache step (id: pnpm-cache using
actions/cache@v4) only caches root node_modules and can break pnpm workspaces;
replace it by using pnpm/action-setup (or actions/setup-node with cache: "pnpm")
so pnpm's content-addressable store is restored by keying on pnpm-lock.yaml, and
remove the Install dependencies conditional on
steps.pnpm-cache.outputs.cache-hit (or if you keep a manual cache, expand the
cache path to include per-package dirs like app/node_modules and adjust uses:
actions/cache accordingly). Ensure references to the pnpm-cache step or
steps.pnpm-cache.outputs.cache-hit are removed or updated (e.g., in the "Install
dependencies" step) when switching to pnpm/action-setup.
In `@docs/BUILDING.md`:
- Around line 103-116: The docs hardcode a Cargo build-script hash in CEF_DIR
which will break when the hash changes; update the wrapper script (the suggested
~/bin/openhuman or a repo-shipped script) to compute CEF_DIR at runtime using a
glob like "$REL_DIR"/build/cef-dll-sys-*/out/cef_linux_aarch64 (or equivalent
shell logic), ensure REL_DIR is set and export LD_LIBRARY_PATH by prepending
that computed CEF_DIR and preserving any existing LD_LIBRARY_PATH, and replace
the hardcoded .deb filename (version 0.52.28) with a glob such as
OpenHuman_*_arm64.deb so the docs remain robust.
In `@package.json`:
- Around line 5-7: Remove the redundant Yarn-style "workspaces" array from
package.json (the top-level "workspaces" key shown in the diff) since pnpm uses
pnpm-workspace.yaml to discover packages; delete that key/entry so the
repository only relies on pnpm-workspace.yaml and avoid confusion from stale
workspace configuration.
🪄 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
Run ID: 7cb55e40-a57e-423c-be80-21f308721622
⛔ Files ignored due to path filters (2)
app/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (13)
.github/workflows/build-windows.yml.github/workflows/build.yml.github/workflows/e2e-agent-review.yml.github/workflows/release.yml.github/workflows/test.yml.github/workflows/typecheck.yml.husky/pre-pushapp/package.jsonapp/src-tauri/src/lib.rsapp/src-tauri/tauri.conf.jsondocs/BUILDING.mdpackage.jsonpnpm-workspace.yaml
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
.github/workflows/build.yml (2)
73-73: Consider--frozen-lockfilein CI for reproducibility.
pnpm install --no-frozen-lockfilelets CI silently mutatepnpm-lock.yamlif anypackage.jsondrifts, which defeats the main reason to commit a lockfile. The PR description notes this relaxation was intentional to unblock the migration, which is fine short-term — but consider switching back topnpm install --frozen-lockfile(or the default, which is frozen in CI) once the lockfile settles. Same applies torelease.ymlandtest.yml.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build.yml at line 73, The CI step currently runs "pnpm install --no-frozen-lockfile" which allows the lockfile to be mutated; update that step to use a frozen install (use "pnpm install --frozen-lockfile" or remove the flag to rely on CI default) in .github/workflows/build.yml and mirror the same change in .github/workflows/release.yml and .github/workflows/test.yml so CI enforces the committed pnpm-lock.yaml for reproducible builds.
62-73: Optional: thenode_modulescache path misses workspace packages in a pnpm layout.In a pnpm workspace, dependencies also materialize under
app/node_modules/(and any other workspace members), not just the repo-rootnode_modules/. Caching onlypath: node_modulesand gatingpnpm installon that cache hit can leaveapp/node_modulesempty on cache restore, causing downstreamcargo tauri build/ vite steps to fail to resolve deps.Since
actions/setup-node'scache: pnpmalready caches the global pnpm store (making reinstalls fast), you can either drop the separateactions/cachestep entirely, or extend itspathto cover all workspace node_modules dirs.♻️ Option A — drop the redundant cache step (simplest)
- - name: Cache node modules - id: pnpm-cache - uses: actions/cache@v4 - with: - path: node_modules - key: ${{ runner.os }}-build-${{ hashFiles('**/pnpm-lock.yaml') }} - restore-keys: | - ${{ runner.os }}-build- - - name: Install dependencies - if: steps.pnpm-cache.outputs.cache-hit != 'true' run: pnpm install --no-frozen-lockfile♻️ Option B — extend the path to cover workspace packages
- name: Cache node modules id: pnpm-cache uses: actions/cache@v4 with: - path: node_modules + path: | + node_modules + app/node_modules key: ${{ runner.os }}-build-${{ hashFiles('**/pnpm-lock.yaml') }} restore-keys: | ${{ runner.os }}-build-🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build.yml around lines 62 - 73, The "Cache node modules" step (id: pnpm-cache) only caches repo-root node_modules and the "Install dependencies" step is gated on its cache-hit, which misses workspace packages (e.g., app/node_modules) in a pnpm workspace; either remove the separate actions/cache step entirely and rely on actions/setup-node with cache: pnpm, or expand the pnpm-cache step's path to include all workspace node_modules (e.g., app/node_modules and any other member dirs) and stop gating the "Install dependencies" run solely on pnpm-cache.outputs.cache-hit so pnpm install still runs when workspace dirs were not restored..github/workflows/test.yml (1)
133-137: Heads up for when the commentede2e-linuxblock is re-enabled.
setup-nodewithcache: "pnpm"requires pnpm on PATH before it runs. The commented block at lines 133-137 (and the commentede2e-macosblock starting at line 228) don't include anInstall pnpmstep, so re-enabling them as-is will fail at the Setup Node step. Additionally, thee2e-macosblock still hascache: "yarn"(line 244) andyarn install/yarn workspaceinvocations (lines 250, 263, 266) that haven't been migrated.Non-blocking since the code is commented out, but worth updating now so the blocks are usable when you flip them on.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/test.yml around lines 133 - 137, The commented e2e-linux and e2e-macos CI blocks reference actions/setup-node with cache: "pnpm" but do not install pnpm on PATH and the macOS block still uses cache: "yarn" and yarn commands; to fix, add an "Install pnpm" step (or ensure pnpm is available) before the actions/setup-node step referenced by the e2e-linux block and change the e2e-macos block to consistently use pnpm by replacing cache: "yarn" with cache: "pnpm" and converting any yarn install / yarn workspace invocations to their pnpm equivalents (or remove caching if you prefer to keep yarn), updating the setup-node usages accordingly so the steps will succeed once the blocks are re-enabled.
🤖 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/test.yml:
- Around line 36-41: Duplicate "Install pnpm" job step is defined twice running
the same command `npm install -g pnpm`; remove the redundant step so only a
single step with name "Install pnpm" that runs `npm install -g pnpm` remains in
the workflow to avoid re-running the install and wasting CI minutes.
In @.github/workflows/typecheck.yml:
- Around line 36-37: The workflow's typecheck job references a non-existent step
id `pnpm-cache` in the conditional `steps.pnpm-cache.outputs.cache-hit`, so the
gate is ineffective; either remove that conditional entirely from the typecheck
job or add a cache step with `id: pnpm-cache` that sets `outputs.cache-hit`
(mirroring the `build` job's cache step) and update the `if:
steps.pnpm-cache.outputs.cache-hit != 'true'` guard to point to that new step;
locate the `typecheck` job and modify the conditional or add a `pnpm-cache` step
to ensure the cache check works as intended.
---
Nitpick comments:
In @.github/workflows/build.yml:
- Line 73: The CI step currently runs "pnpm install --no-frozen-lockfile" which
allows the lockfile to be mutated; update that step to use a frozen install (use
"pnpm install --frozen-lockfile" or remove the flag to rely on CI default) in
.github/workflows/build.yml and mirror the same change in
.github/workflows/release.yml and .github/workflows/test.yml so CI enforces the
committed pnpm-lock.yaml for reproducible builds.
- Around line 62-73: The "Cache node modules" step (id: pnpm-cache) only caches
repo-root node_modules and the "Install dependencies" step is gated on its
cache-hit, which misses workspace packages (e.g., app/node_modules) in a pnpm
workspace; either remove the separate actions/cache step entirely and rely on
actions/setup-node with cache: pnpm, or expand the pnpm-cache step's path to
include all workspace node_modules (e.g., app/node_modules and any other member
dirs) and stop gating the "Install dependencies" run solely on
pnpm-cache.outputs.cache-hit so pnpm install still runs when workspace dirs were
not restored.
In @.github/workflows/test.yml:
- Around line 133-137: The commented e2e-linux and e2e-macos CI blocks reference
actions/setup-node with cache: "pnpm" but do not install pnpm on PATH and the
macOS block still uses cache: "yarn" and yarn commands; to fix, add an "Install
pnpm" step (or ensure pnpm is available) before the actions/setup-node step
referenced by the e2e-linux block and change the e2e-macos block to consistently
use pnpm by replacing cache: "yarn" with cache: "pnpm" and converting any yarn
install / yarn workspace invocations to their pnpm equivalents (or remove
caching if you prefer to keep yarn), updating the setup-node usages accordingly
so the steps will succeed once the blocks are re-enabled.
🪄 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
Run ID: a9f6e544-032c-4a8d-9507-724be7971c58
⛔ Files ignored due to path filters (1)
app/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (8)
.github/workflows/build-windows.yml.github/workflows/build.yml.github/workflows/e2e-agent-review.yml.github/workflows/release.yml.github/workflows/test.yml.github/workflows/typecheck.ymlapp/scripts/e2e-build.shapp/src-tauri/src/lib.rs
🚧 Files skipped from review as they are similar to previous changes (3)
- app/src-tauri/src/lib.rs
- .github/workflows/build-windows.yml
- .github/workflows/e2e-agent-review.yml
| - name: Install pnpm | ||
| run: npm install -g pnpm | ||
|
|
||
| - name: Install pnpm | ||
| run: npm install -g pnpm | ||
|
|
There was a problem hiding this comment.
Duplicate Install pnpm step — remove one.
The same step is defined twice consecutively. npm install -g pnpm is idempotent so it doesn't break the job, but it re-runs the install and wastes CI minutes.
🐛 Proposed fix
- name: Install pnpm
run: npm install -g pnpm
- - name: Install pnpm
- run: npm install -g pnpm
-
- name: Setup Node.js 24.x🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/test.yml around lines 36 - 41, Duplicate "Install pnpm"
job step is defined twice running the same command `npm install -g pnpm`; remove
the redundant step so only a single step with name "Install pnpm" that runs `npm
install -g pnpm` remains in the workflow to avoid re-running the install and
wasting CI minutes.
- Document aarch64 build process in BUILDING.md - Add gtk::init() in tauri-runtime-cef before tray creation - This fixes 'GTK has not been initialized' panic on ARM Linux
- Add aarch64 build and run instructions to BUILDING.md - Add gtk::init() before tray creation in tauri-runtime-cef - Fixes 'GTK has not been initialized' panic on ARM Linux
…e externalBin - Migrate package.json scripts from yarn to pnpm - Add linux deb bundle config with empty depends in tauri.conf.json - Remove duplicate externalBin key in tauri.conf.json - Add pnpm workspace and lockfiles Amp-Thread-ID: https://ampcode.com/threads/T-019dbb86-6270-709c-ba2e-0dc4ed254adc Co-authored-by: Amp <amp@ampcode.com>
The commit 4fc849cc is not yet available in the remote. Using the latest available commit c8ece7c78 from origin/feat/cef. The GTK init fix is available via separate PR: tinyhumansai/tauri-cef#8
tinyhumansai#803) Co-authored-by: Jwalin Shah <jshah1331@gmail.com> Co-authored-by: Steven Enamakel <enamakel@tinyhumans.ai>
…umansai#395) (tinyhumansai#782) Co-authored-by: Jwalin Shah <jshah1331@gmail.com> Co-authored-by: Steven Enamakel <enamakel@tinyhumans.ai>
Co-authored-by: Jwalin Shah <jshah1331@gmail.com>
…i#710) (tinyhumansai#839) - Add JSON-RPC handlers for source, global, and topic-based memory retrieval. - Integrate Ollama embeddings for semantic reranking of chunks and summaries. - Implement 15 unit tests for RPC handlers covering parameter parsing and PII redaction. - Redact PII from logs by removing raw source, entity, and node identifiers. - Fix BFS traversal for drill-down and deduplicate results in topic queries. - Add configuration for embedding endpoints, models, and strictness modes. Co-authored-by: sanil-23 <sanil@vezures.xyz> Co-authored-by: Steven Enamakel <enamakel@tinyhumans.ai>
…LLM-summarised squash bodies (tinyhumansai#849)
- Update all workflows to use pnpm instead of yarn - Change cache: yarn to cache: pnpm - Change yarn install to pnpm install - Change yarn workspace to pnpm --filter - Guard setup_tray with warn log level for headless CI environments
Also fix E2E spec pattern resolution from app/ directory
tauri-driver v2.0.5 proxies to WebKitWebDriver (webkit2gtk), but this app uses CEF (tauri-runtime-cef) which has no WebDriver automation. Sessions hang and timeout. Same as the commented-out e2e_linux job in test.yml. Keep workflow_dispatch for manual runs when CEF automation support lands.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
So many Unnecessary Commits. Closing this for now And creating a New Pull Request once everything is fixed. |
Sync branch with latest commits from original PR #840 (linux-arm-build)
Summary by CodeRabbit
Documentation
Chores
Bug Fixes
New Features