Fix some release workflow inefficiencies.

[vorporeal]

Description

Release builds were doing avoidable recompilation because some same-host cross-compilation jobs shared the default Rust cache key, and settings schema generation did not use the feature set from the primary Warp build.

This adds target-architecture cache keys to the macOS release matrices and forwards selected Cargo features through the bundled-resource preparation paths used by macOS, Linux, and Windows release bundles. That lets compatible release jobs restore the correct cache and reuse existing warp library artifacts while generating the settings schema.

Testing

• git diff --check origin/master...HEAD
• bash -n script/linux/bundle script/linux/bundle_install script/macos/bundle script/prepare_bundled_resources
• Parsed script/windows/bundle.ps1 and script/windows/prepare_bundled_resources.ps1 with the PowerShell parser
• actionlint .github/workflows/create_release.yml (reports existing ShellCheck warnings and unknown custom runner labels unrelated to this diff)

CHANGELOG-NONE

Co-Authored-By: Oz oz-agent@warp.dev

[vorporeal]

• Fix some release workflow inefficiencies. #12884 👈 (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.

You can view the conversation on Warp.

I completed the review and no human review was requested for 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 separates macOS Rust cache keys by target architecture and forwards the release bundle Cargo features into settings schema generation for macOS, Linux, and Windows bundled resources.

Concerns

• The feature-aware settings schema generation still uses a single SETTINGS_SCHEMA_CACHE path. In release_linux_arm, the app package generation and CLI package generation run sequentially in the same job with different feature sets, so the second artifact can reuse a schema generated for the first artifact.

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] SETTINGS_SCHEMA_CACHE is shared across multiple prepare_bundled_resources calls in release_linux_arm, but the schema now depends on CARGO_FEATURES; after the app bundle populates the cache, the CLI bundle can copy an app-feature schema instead of regenerating with standalone. Include the feature set in the cache key/path or invalidate the cache when CARGO_FEATURES differs.