feat(just): add desktop-release-run to test a checkout with the installed app's state - #6915
feat(just): add desktop-release-run to test a checkout with the installed app's state#6915baxen wants to merge 1 commit into
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>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
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 👍 / 👎.
1 participant
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.