Fix schema generator binary recompilation during release bundling.

[vorporeal]

Description

The release bundling workflow runs prepare_bundled_resources after the main cargo build, and that script in turn invokes cargo run --bin generate_settings_schema. Until now we passed neither --features nor --target to this run, so cargo's resolver-v2 saw a different per-package feature unification than the main build and recompiled every dependency whose enabled features differed (rust-embed with debug-embed, warp_core's release_bundle, sentry, jemalloc, etc.). This added significant time to release builds and pulled in extra system dependencies (e.g. protoc) for jobs that should otherwise just be packaging the prebuilt binary.

There was a secondary correctness issue: the schema generator iterates settings registered via inventory::submit!, and #[cfg(feature = \"...\")]-gated settings were silently omitted from the schema in any context whose feature set didn't match the main binary.

The fix threads the build's feature set (and target, where applicable) through to the schema-generator invocation, and makes package selection explicit with -p warp. With matching features and target, cargo reuses the existing compilation artifacts; with the same feature set, the generated schema is also faithful to what the bundled binary actually exposes.

Testing

Verified bash -n syntax for the modified bash scripts and parsed the modified PowerShell files via pwsh. Bundling, schema generation, and CI behavior will be exercised by this PR's release builds.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Conversation

[vorporeal]

• Fix schema generator binary recompilation during release bundling. #9632 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[oz-for-oss]

@vorporeal

I'm starting a first review of this pull request.

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

You can view the conversation on Warp.

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR threads cargo features, profiles, targets, and explicit package selection into settings-schema generation during bundled-resource preparation so release jobs can better reuse build artifacts and include feature-gated settings.

Concerns

• Windows arm64 packaging runs on the same x64 windows-latest-large runner as x64 packaging, but the new target forwarding makes cargo run build and execute generate_settings_schema for aarch64-pc-windows-msvc. That target binary is not executable on the x64 runner, so the arm64 release job will fail during bundled-resource preparation.
• Supplemental security pass: no security issues found in the changed command construction; shell/PowerShell invocations pass feature and target values as argv elements rather than interpolating them into an evaluated shell string.

Verdict

Found: 0 critical, 1 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

⚠️ [IMPORTANT] This breaks the Windows arm64 release job: the matrix uses the x64 windows-latest-large runner for --arch arm64, so passing -CargoTarget aarch64-pc-windows-msvc makes cargo run build and try to execute an arm64 generate_settings_schema binary on an x64 host. Only pass CargoTarget when the target is runnable on the current host, or leave schema generation as a host-target run for cross-compiled Windows artifacts.

[oz-for-oss]

Overview

This PR threads the bundling feature set and runnable cargo target into settings schema generation across the Linux, macOS, and Windows resource-preparation scripts, while making the schema generator package selection explicit.

Concerns

• script/macos/run still drops the selected --profile when --generate-schema is used, so that local path can compile the schema generator with the default dev profile even when cargo bundle used another profile.
• Supplemental security pass: no command-injection or secret-handling issues found in the changed argument forwarding; shell and PowerShell invocations keep user-supplied feature/target strings as single argv entries.

Verdict

Found: 0 critical, 0 important, 1 suggestions

Approve with nits

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

💡 [SUGGESTION] --profile is parsed above into PROFILE and forwarded to cargo bundle; passing an empty profile here makes --generate-schema --profile ... compile the schema generator in dev instead of reusing the bundle profile.

Suggested change

	# Pass FEATURES through (and an empty cargo profile, since this script does
	# not configure one) so that the schema generation reuses the same compiled
	# artifacts as the cargo bundle invocation above.
	NO_LICENSES=1 "${REPO_ROOT}/script/prepare_bundled_resources" "$WARP_APP_PATH/Contents/Resources" "$WARP_CHANNEL" "" "$FEATURES"
	# Pass the cargo profile and features through so schema generation can reuse
	# the same compiled artifacts as the cargo bundle invocation above.
	NO_LICENSES=1 "${REPO_ROOT}/script/prepare_bundled_resources" "$WARP_APP_PATH/Contents/Resources" "$WARP_CHANNEL" "${PROFILE:-}" "$FEATURES"