Conversation
…lled app's state Every tauri-dev recipe (dev, staging, production, desktop-standalone) is a debug build, and debug builds are hardwired to the dev keyring, the xyz.block.buzz.app.dev.* app-data dir, and the ~/.buzz-dev nest. None of them can open the installed app's identity, communities, or managed agents, so 'run the app with my real setup plus my code changes' had no recipe. desktop-release-run builds release sidecars and an unsigned release Buzz.app with the stock tauri.conf.json identifier, verifies the bundle id is xyz.block.buzz.app, quits the running Buzz (single-instance would otherwise forward the launch to it), and opens the new bundle. macOS only; mesh opt-in via mesh=1 like the other recipes. Signed-off-by: Fizz <400e8babadcee6a7f420103f10a2849d84c4a9c71d5bd04f3948c814216648a3@buzz.block.builderlab.xyz>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad280807fe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # Must NOT pass --config: the stock tauri.conf.json identifier is what maps | ||
| # this build onto the installed app's state. | ||
| pnpm tauri build --no-sign --bundles app ${FEATURES[@]+"${FEATURES[@]}"} | ||
| APP="${TARGET_DIR}/release/bundle/macos/Buzz.app" |
There was a problem hiding this comment.
TARGET_DIR comes from cargo metadata executed at the repository root, so without an explicit CARGO_TARGET_DIR it resolves to <repo>/target. The desktop crate is excluded from that workspace, and pnpm tauri build runs in its separate workspace under desktop/src-tauri, producing the app at <repo>/desktop/src-tauri/target/release/bundle/macos/Buzz.app. Consequently, on a normal macOS checkout the subsequent defaults read targets a nonexistent bundle and the new recipe fails after completing the release build instead of launching the app.
Useful? React with 👍 / 👎.
) ## Summary Carl, an automated agent, implementing on Wes's request. Fix ordinary Desktop dev checkouts being misclassified as linked worktrees when launched through `just production`, `staging`, or other recipes that source `instance-env.sh` from `desktop/`. From the repository root, Git reports both directories as `.git`. From `desktop/`, it can report an absolute `--git-dir` and `../.git` for `--git-common-dir`. The textual comparison treats them as different and chooses a branch-suffixed app profile (for example `.dev.main`) instead of the canonical `.dev` profile populated by the agent-adoption script. - Request `--path-format=absolute` for both paths. Actual linked worktrees still have distinct Git/common directories and retain their existing isolated app identities. - Add eight isolated fixture cases executing the real environment script with real Git: ordinary root/subdirectory on main and feature branches, linked root/subdirectory, detached linked subdirectory, and symlinked ordinary subdirectory. Paths contain spaces. Only native icon generation is stubbed; no user profile, keychain, app, or relay is accessed. - Run the regression in the existing always-run CI contract job. No agent migration, global-settings copy, keychain changes, profile merging, branch-label redesign, or packaged-release behavior changes. Existing Git `--path-format` support is required (Git 2.31+). ### Related issue Searched open PRs for `instance-env` and worktree titles, and open issues for dev-profile/adoption reports. No matching path-normalization fix found. - #7142 touches `instance-env.sh` for descriptive labels. This fix is independent; it uses a distinct test filename to avoid colliding with that PR's new `test-instance-env.sh`. - #6915 proposes a separate release-profile launch recipe; this fix preserves the current dev-profile contract instead. ### Testing At exact head `0a09a2f3716b0378546b66be2302b750ed4330b9`: - `scripts/test-desktop-instance-detection.sh`: **8/8 passed**. - Before the production change, the same regression failed on the ordinary checkout's `desktop/` case: actual `xyz.block.buzz.app.dev.main`, expected `xyz.block.buzz.app.dev`. - `bash -n scripts/instance-env.sh scripts/test-desktop-instance-detection.sh`: passed. - `git diff --check`: passed before commit; pre-commit and commit-msg hooks completed. - Applicable pre-push gates passed: branch-skew, push-head-scope, and file-size policy (6 tests plus all three entrypoints). Rust/Desktop/Mobile package lanes were correctly inapplicable to this shell/CI-only diff. No native app launch or first-boot key import was performed. The validated boundary is the generated launch environment/profile identity, not successful agent startup. Hosted CI has not been checked or represented as green. Signed-off-by: Wes <wesbillman@users.noreply.github.com> Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz>
wesbillman
left a comment
There was a problem hiding this comment.
Carl, an automated reviewer, commenting via Wes’s GitHub account.
Changes requested
Reviewed head ad280807fec05fc8bf27f9ccd883a1719c6ef2d5 against base cada3028ceda7ebdae61329f15b5364ca0d23dd4.
1. [P2] Resolve the app bundle from the Desktop workspace, not the sidecar workspace
TARGET_DIR is obtained at line 303 by running cargo metadata at the repository root. That is the correct output directory for the sidecars, but not for the Tauri app: root Cargo.toml:35 excludes desktop/src-tauri, whose Cargo.toml:1-6 declares a separate workspace. Neither the checked-in Cargo configuration nor this recipe gives the two workspaces a shared target directory.
In the normal environment without a shared absolute CARGO_TARGET_DIR, pnpm tauri build therefore writes the new app to <repo>/desktop/src-tauri/target/release/bundle/macos/Buzz.app, while line 314 checks <repo>/target/release/bundle/macos/Buzz.app. The pinned Tauri CLI 2.11.4 confirms this: get_cargo_metadata runs in the Tauri directory, and get_cargo_target_dir uses that metadata.
Reproduction by source trace: run the new recipe in a standard checkout without CARGO_TARGET_DIR. After a successful release build, defaults read fails on the nonexistent root-workspace bundle and set -e aborts before launch. If an older same-identifier bundle exists at that wrong path, the identifier-only guard instead accepts it and launches stale code while printing the current checkout's SHA. The documented local-testing workflow must select the bundle it just built.
Keep separate target-directory values for sidecars and Desktop, querying metadata with the Desktop manifest/directory, or explicitly make the build and launch agree on a shared absolute target directory. Verify the default separate-workspace case as well as any supported shared-target configuration; include a stale bundle at the other path to guard against launching the wrong artifact.
2. [P2] Wait only for the production-identity instance to exit
The predicate matches every process named buzz-desktop, but AppleScript quits only the application identified by xyz.block.buzz.app. A normal just dev/standalone instance also runs the Cargo binary buzz-desktop (desktop/src-tauri/Cargo.toml:8-10, src/main.rs), while scripts/instance-env.sh:28,92 gives it a separate xyz.block.buzz.app.dev... identity specifically so it can coexist with production.
Reproduction by source trace: with the bundle-path issue corrected or a shared target directory configured, leave a dev instance running and invoke desktop-release-run. Even when the production app has exited, the unrelated dev process keeps all three pgrep -xq buzz-desktop checks true. After 30 seconds the recipe aborts without launching the new release app. This prevents the intended local release testing alongside an isolated dev session; quitting that unrelated session should not be a prerequisite.
Resolve and wait for the process(es) belonging to the production bundle identity rather than the shared executable name. Cover production-only, dev-only, and both-running cases, preserving the dev process while refusing to launch if the production instance cannot quit.
Scope and validation
The intentional contract is an unsigned, macOS-only local release build using the installed app's identity, communities, and managed-agent state, with mesh opt-in. Sharing that state is not itself a finding. Reviewed recipe prerequisites, sidecar inventory, build/configuration selection, release keyring/nest selection, and launch/shutdown handoff. Non-macOS execution and distributable release packaging remain out of scope.
Source-only review of pinned, blob-verified repository files and the pinned Tauri CLI implementation, with an independent launch/shutdown review integrated. No PR recipe, code, builds, tests, or installs executed; actual app launch and keychain prompts were not exercised.
Why
"Run Buzz from my checkout, but with my real identity, communities, and agents" had no recipe. Every
tauri devrecipe (dev,staging,production,desktop-standalone) is a debug build, and debug builds are hardwired to the dev stores:tauri dev)buzz-desktop-dev*(app_state_keyring.rs:10,cfg!(debug_assertions))buzz-desktopxyz.block.buzz.app.dev.*(scripts/instance-env.sh)xyz.block.buzz.app~/.buzz-dev(managed_agents/nest.rs)~/.buzzdesktop-standaloneadditionally scopes the keyring per-instance (buzz-desktop-dev.<slug>), so each checkout starts from onboarding.just productiononly changes the relay URL; the agent roster is still the dev one.What
just desktop-release-run(macOS):desktop/src-tauri/binaries/pnpm tauri build --no-sign --bundles appwith the stocktauri.conf.json(no--config), so the bundle id isxyz.block.buzz.appopens the new bundleMesh is opt-in via
mesh=1, matching the other desktop recipes. Unsigned, local-testing only.Verified
Ran the recipe body on this branch (base
cada3028c): cold release build ~4.5 min, bundle idxyz.block.buzz.app, all 6 sidecars +buzz-desktoppresent inContents/MacOS.just --listrenders the one-line doc;just -nexpands cleanly.