Optimize settings schema generation during release process. - #13240
Merged
vorporeal merged 16 commits intoAug 23, 2026
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
vorporeal
force-pushed
the
david/optimize-settings-schema-generation-during-release
branch
from
August 21, 2026 19:50
0e89a7b to
8636f33
Compare
Comment on lines
+556
to
+665
| name: Build Release Binary (macOS TUI ${{ matrix.arch }}) | ||
| runs-on: macos-26-xlarge | ||
| needs: prepare_release | ||
| if: ${{ inputs.build_macos != false }} | ||
| timeout-minutes: 60 | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| include: | ||
| - arch: aarch64 | ||
| - arch: x86_64 | ||
| steps: | ||
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6 | ||
|
|
||
| - uses: ./.github/actions/prepare_environment | ||
| with: | ||
| target_os: macos | ||
| is_self_hosted: false | ||
| ref: ${{ needs.prepare_release.outputs.release_branch }} | ||
| install_release_deps: true | ||
| ssh_key: ${{ secrets.WARP_CHANNEL_CONFIG_ACCESS_SSH_KEY }} | ||
|
|
||
| - name: Ensure rust target is installed | ||
| run: rustup target add ${{ matrix.arch }}-apple-darwin | ||
| shell: bash | ||
|
|
||
| # Install go toolchain, as it may be needed for some build steps. | ||
| - name: Setup Go | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6 | ||
| with: | ||
| go-version: stable | ||
|
|
||
| - name: Get channel configuration | ||
| id: get-config | ||
| uses: ./.github/actions/get_channel_config/ | ||
| with: | ||
| config_file: ${{ env.CONFIG_FILE }} | ||
| channel: ${{ inputs.channel }} | ||
|
|
||
| # Only the binary matters here; this job's own bundled resources are | ||
| # discarded, so skip signing/notarization and the (otherwise mandatory) | ||
| # schema, both of which belong to the packaging step below. | ||
| - name: Build ${{ matrix.arch }} binary | ||
| id: build_tui | ||
| run: | | ||
| script/bundle --channel $CHANNEL --arch ${{ matrix.arch }} --artifact tui --nosign | ||
| shell: bash | ||
| env: | ||
| CHANNEL: ${{ steps.get-config.outputs.channel }} | ||
| GIT_RELEASE_TAG: ${{ needs.prepare_release.outputs.release_tag }} | ||
| NO_LICENSES: "1" | ||
| SKIP_SETTINGS_SCHEMA: "1" | ||
|
|
||
| # binary_path is already copied out of the per-target-triple Cargo output | ||
| # directory; --skip-build (used by release_macos_tui below) re-derives | ||
| # that copy from the triple directory, so preserve it here instead. | ||
| - name: Create tar archive with build artifacts | ||
| run: | | ||
| BINARY_PATH="${{ steps.build_tui.outputs.binary_path }}" | ||
| PROFILE_DIR="${BINARY_PATH#target/}" | ||
| PROFILE_DIR="${PROFILE_DIR%/bundle/osx/*}" | ||
| RAW_BINARY_PATH="target/${{ steps.build_tui.outputs.rust_target }}/$PROFILE_DIR/$(basename "$BINARY_PATH")" | ||
| TAR_PATHS=("$RAW_BINARY_PATH") | ||
| if [[ -e "$RAW_BINARY_PATH.dSYM" ]]; then | ||
| TAR_PATHS+=("$RAW_BINARY_PATH.dSYM") | ||
| fi | ||
| tar czfv build-artifacts.tar.gz "${TAR_PATHS[@]}" | ||
| shell: bash | ||
|
|
||
| - name: Archive ${{ matrix.arch }} TUI build artifacts | ||
| uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 | ||
| with: | ||
| name: macos-tui-${{ matrix.arch }}-${{ steps.get-config.outputs.channel }} | ||
| retention-days: 1 | ||
| # We compress the tar archive, so no need to re-compress. | ||
| compression-level: 0 | ||
| path: build-artifacts.tar.gz | ||
|
|
||
| release_macos_tui: | ||
| name: Build Release (macOS TUI ${{ matrix.arch }}) | ||
| runs-on: macos-26-xlarge | ||
| needs: [prepare_release, release_macos_single_arch, build_macos_tui_binaries] | ||
| if: ${{ inputs.build_macos != false }} | ||
| timeout-minutes: 60 | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| include: | ||
| - arch: aarch64 | ||
| - arch: x86_64 | ||
| steps: | ||
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6 | ||
|
|
||
| - uses: ./.github/actions/prepare_environment | ||
| with: | ||
| target_os: macos | ||
| is_self_hosted: false | ||
| ref: ${{ needs.prepare_release.outputs.release_branch }} | ||
| install_release_deps: true | ||
| ssh_key: ${{ secrets.WARP_CHANNEL_CONFIG_ACCESS_SSH_KEY }} | ||
|
|
||
| # Install go toolchain, as it may be needed for some build steps. | ||
| - name: Setup Go | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6 | ||
| with: | ||
| go-version: stable | ||
|
|
||
| - name: Get channel configuration | ||
| id: get-config | ||
| uses: ./.github/actions/get_channel_config/ |
Contributor
|
This PR was generated with Warp. Comment    |
Comment on lines
+445
to
+562
| name: Build Release Binary (macOS CLI ${{ matrix.arch }}) | ||
| runs-on: macos-26-xlarge | ||
| needs: prepare_release | ||
| if: ${{ inputs.build_macos != false }} | ||
| timeout-minutes: 60 | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| include: | ||
| - arch: aarch64 | ||
| - arch: x86_64 | ||
| steps: | ||
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6 | ||
|
|
||
| - uses: ./.github/actions/prepare_environment | ||
| with: | ||
| target_os: macos | ||
| is_self_hosted: false | ||
| ref: ${{ needs.prepare_release.outputs.release_branch }} | ||
| install_release_deps: true | ||
| ssh_key: ${{ secrets.WARP_CHANNEL_CONFIG_ACCESS_SSH_KEY }} | ||
|
|
||
| - name: Ensure rust target is installed | ||
| run: rustup target add ${{ matrix.arch }}-apple-darwin | ||
| shell: bash | ||
|
|
||
| # Install go toolchain, as it may be needed for some build steps. | ||
| - name: Setup Go | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6 | ||
| with: | ||
| go-version: stable | ||
|
|
||
| - name: Get channel configuration | ||
| id: get-config | ||
| uses: ./.github/actions/get_channel_config/ | ||
| with: | ||
| config_file: ${{ env.CONFIG_FILE }} | ||
| channel: ${{ inputs.channel }} | ||
|
|
||
| # Only the binary matters here; this job's own bundled resources are | ||
| # discarded, so skip signing/notarization and the (otherwise mandatory) | ||
| # schema, both of which belong to the packaging step below. | ||
| - name: Build ${{ matrix.arch }} binary | ||
| id: build_cli | ||
| run: | | ||
| script/bundle --channel $CHANNEL --arch ${{ matrix.arch }} --artifact cli --nosign | ||
| shell: bash | ||
| env: | ||
| CHANNEL: ${{ steps.get-config.outputs.channel }} | ||
| GIT_RELEASE_TAG: ${{ needs.prepare_release.outputs.release_tag }} | ||
| NO_LICENSES: "1" | ||
| SKIP_SETTINGS_SCHEMA: "1" | ||
|
|
||
| # binary_path is already copied out of the per-target-triple Cargo output | ||
| # directory; --skip-build (used by release_macos_cli below) re-derives | ||
| # that copy from the triple directory, so preserve it here instead. The | ||
| # dSYM Cargo produces there is itself a symlink into target/.../deps, so | ||
| # (as with the app archive above) also include its resolved target; | ||
| # otherwise the link dangles once extracted into a fresh job. | ||
| - name: Create tar archive with build artifacts | ||
| run: | | ||
| BINARY_PATH="${{ steps.build_cli.outputs.binary_path }}" | ||
| PROFILE_DIR="${BINARY_PATH#target/}" | ||
| PROFILE_DIR="${PROFILE_DIR%/bundle/osx/*}" | ||
| RAW_BINARY_PATH="target/${{ steps.build_cli.outputs.rust_target }}/$PROFILE_DIR/$(basename "$BINARY_PATH")" | ||
| RAW_DSYM_PATH="$RAW_BINARY_PATH.dSYM" | ||
| TAR_PATHS=("$RAW_BINARY_PATH") | ||
| if [[ -e "$RAW_DSYM_PATH" ]]; then | ||
| TAR_PATHS+=("$RAW_DSYM_PATH") | ||
| if [[ -L "$RAW_DSYM_PATH" ]]; then | ||
| REAL_DSYM_PATH="$(python3 -c 'import os,sys; print(os.path.relpath(sys.argv[1]))' "$(realpath "$RAW_DSYM_PATH")")" | ||
| TAR_PATHS+=("$REAL_DSYM_PATH") | ||
| fi | ||
| fi | ||
| tar czfv build-artifacts.tar.gz "${TAR_PATHS[@]}" | ||
| shell: bash | ||
|
|
||
| - name: Archive ${{ matrix.arch }} CLI build artifacts | ||
| uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 | ||
| with: | ||
| name: macos-cli-${{ matrix.arch }}-${{ steps.get-config.outputs.channel }} | ||
| retention-days: 1 | ||
| # We compress the tar archive, so no need to re-compress. | ||
| compression-level: 0 | ||
| path: build-artifacts.tar.gz | ||
|
|
||
| release_macos_cli: | ||
| name: Build Release (macOS CLI ${{ matrix.arch }}) | ||
| runs-on: macos-26-xlarge | ||
| needs: [prepare_release, release_macos_single_arch, build_macos_cli_binaries] | ||
| if: ${{ inputs.build_macos != false }} | ||
| timeout-minutes: 60 | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| include: | ||
| - arch: aarch64 | ||
| - arch: x86_64 | ||
| steps: | ||
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6 | ||
|
|
||
| - uses: ./.github/actions/prepare_environment | ||
| with: | ||
| target_os: macos | ||
| is_self_hosted: false | ||
| ref: ${{ needs.prepare_release.outputs.release_branch }} | ||
| install_release_deps: true | ||
| ssh_key: ${{ secrets.WARP_CHANNEL_CONFIG_ACCESS_SSH_KEY }} | ||
|
|
||
| # Install go toolchain, as it may be needed for some build steps. | ||
| - name: Setup Go | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6 | ||
| with: | ||
| go-version: stable | ||
|
|
||
| - name: Get channel configuration | ||
| id: get-config | ||
| uses: ./.github/actions/get_channel_config/ |
Comment on lines
+563
to
+761
| with: | ||
| config_file: ${{ env.CONFIG_FILE }} | ||
| channel: ${{ inputs.channel }} | ||
|
|
||
| - name: Download ${{ matrix.arch }} CLI build artifacts | ||
| uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1 | ||
| with: | ||
| name: macos-cli-${{ matrix.arch }}-${{ steps.get-config.outputs.channel }} | ||
|
|
||
| - name: Extract CLI build artifacts | ||
| run: tar xvfz build-artifacts.tar.gz | ||
| shell: bash | ||
|
|
||
| - name: Download canonical macOS settings schema | ||
| uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1 | ||
| with: | ||
| name: settings-schema-macos-aarch64-${{ steps.get-config.outputs.channel }} | ||
| path: .release-artifacts/settings-schema-macos | ||
|
|
||
| - name: Bundle ${{ matrix.arch }} binary | ||
| id: bundle_cli | ||
| run: | | ||
| script/bundle --read-passwords-from-env --channel $CHANNEL --arch ${{ matrix.arch }} --artifact cli | ||
| script/bundle --skip-build --read-passwords-from-env --channel $CHANNEL --arch ${{ matrix.arch }} --artifact cli | ||
| shell: bash | ||
| env: | ||
| CHANNEL: ${{ steps.get-config.outputs.channel }} | ||
| GIT_RELEASE_TAG: ${{ needs.prepare_release.outputs.release_tag }} | ||
| WARP_DEVELOPER_ID_CERT: ${{ secrets.WARP_DEVELOPER_ID_CERT }} | ||
| WARP_DEVELOPER_ID_CERT_PASSWORD: ${{ secrets.WARP_DEVELOPER_ID_CERT_PASSWORD }} | ||
| WARP_CODESIGN_KEYCHAIN_PASSWORD: ${{ secrets.WARP_CODESIGN_KEYCHAIN_PASSWORD }} | ||
| WARP_NOTARIZATION_APPLE_ID: ${{ secrets.WARP_NOTARIZATION_APPLE_ID }} | ||
| WARP_NOTARIZATION_PASSWORD: ${{ secrets.WARP_NOTARIZATION_PASSWORD }} | ||
| SETTINGS_SCHEMA_SOURCE: ${{ github.workspace }}/.release-artifacts/settings-schema-macos/settings_schema.json | ||
|
|
||
| - name: Package CLI binary | ||
| run: | | ||
| mv ${{ steps.bundle_cli.outputs.binary_path }} oz-${{ steps.get-config.outputs.channel }} | ||
| tar czf oz-${{ steps.get-config.outputs.channel }}-macos-${{ matrix.arch }}.tar.gz oz-${{ steps.get-config.outputs.channel }} -C "$(dirname "${{ steps.bundle_cli.outputs.bundled_resources_dir }}")" resources | ||
|
|
||
| - name: Add CLI to GitHub release assets | ||
| if: ${{ needs.prepare_release.outputs.should_publish == 'true' }} | ||
| uses: softprops/action-gh-release@3d0d9888cb7fd7b750713d6e236d1fcb99157228 # v3.0.2 | ||
| with: | ||
| tag_name: ${{ needs.prepare_release.outputs.release_tag }} | ||
| files: oz-${{ steps.get-config.outputs.channel }}-macos-${{ matrix.arch }}.tar.gz | ||
| token: ${{ secrets.GITHUB_TOKEN }} | ||
|
|
||
| - uses: google-github-actions/auth@7c6bc770dae815cd3e89ee6cdf493a5fab2cc093 # v3.0.0 | ||
| if: ${{ needs.prepare_release.outputs.should_publish == 'true' }} | ||
| with: | ||
| credentials_json: ${{ secrets.GOOGLE_APPLICATION_CREDENTIALS }} | ||
|
|
||
| - name: Upload CLI to Google Cloud Storage | ||
| if: ${{ needs.prepare_release.outputs.should_publish == 'true' }} | ||
| uses: google-github-actions/upload-cloud-storage@e95a15f226403ed658d3e65f40205649f342ba2c # v1 | ||
| with: | ||
| path: oz-${{ steps.get-config.outputs.channel }}-macos-${{ matrix.arch }}.tar.gz | ||
| destination: warp-releases/${{ steps.get-config.outputs.channel }}/${{ needs.prepare_release.outputs.release_tag }}/cli/macos/${{ matrix.arch }} | ||
| headers: |- | ||
| cache-control: ${{ steps.get-config.outputs.gcs_cache_control_value }} | ||
|
|
||
| - name: Upload CLI as workflow artifact | ||
| if: ${{ needs.prepare_release.outputs.should_publish != 'true' }} | ||
| uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 | ||
| with: | ||
| name: release-macos-cli-${{ matrix.arch }}-${{ steps.get-config.outputs.channel }} | ||
| path: oz-${{ steps.get-config.outputs.channel }}-macos-${{ matrix.arch }}.tar.gz | ||
|
|
||
| - name: Set up Sentry CLI | ||
| if: ${{ needs.prepare_release.outputs.should_publish == 'true' }} | ||
| uses: matbour/setup-sentry-cli@3e938c54b3018bdd019973689ef984e033b0454b # v2.0.0 | ||
| with: | ||
| token: ${{ secrets.SENTRY_RELEASE_TOKEN }} | ||
| organization: warpdotdev | ||
| project: ${{ steps.get-config.outputs.sentry_project }} | ||
|
|
||
| - name: Upload debugging symbols to Sentry | ||
| if: ${{ needs.prepare_release.outputs.should_publish == 'true' }} | ||
| run: | | ||
| script/sentry_upload_dif.sh | ||
| shell: bash | ||
| env: | ||
| DEBUG_FILE_OR_FOLDER_PATH: ${{ steps.bundle_cli.outputs.dsym_path }} | ||
|
|
||
| release_macos_tui: | ||
| name: Build Release (macOS TUI ${{ matrix.arch }}) | ||
| # Builds the TUI binary only, with no dependency on release_macos_single_arch, | ||
| # so this heavy build+notarize step keeps running in parallel with the app | ||
| # build instead of serializing behind it. Packaging (which needs the | ||
| # canonical schema release_macos_single_arch produces) happens in | ||
| # release_macos_tui below, mirroring the build_windows_binaries / | ||
| # release_windows split. | ||
| build_macos_tui_binaries: | ||
| name: Build Release Binary (macOS TUI ${{ matrix.arch }}) | ||
| runs-on: macos-26-xlarge | ||
| needs: prepare_release | ||
| if: ${{ inputs.build_macos != false }} | ||
| timeout-minutes: 60 | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| include: | ||
| - arch: aarch64 | ||
| - arch: x86_64 | ||
| steps: | ||
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6 | ||
|
|
||
| - uses: ./.github/actions/prepare_environment | ||
| with: | ||
| target_os: macos | ||
| is_self_hosted: false | ||
| ref: ${{ needs.prepare_release.outputs.release_branch }} | ||
| install_release_deps: true | ||
| ssh_key: ${{ secrets.WARP_CHANNEL_CONFIG_ACCESS_SSH_KEY }} | ||
|
|
||
| - name: Ensure rust target is installed | ||
| run: rustup target add ${{ matrix.arch }}-apple-darwin | ||
| shell: bash | ||
|
|
||
| # Install go toolchain, as it may be needed for some build steps. | ||
| - name: Setup Go | ||
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6 | ||
| with: | ||
| go-version: stable | ||
|
|
||
| - name: Get channel configuration | ||
| id: get-config | ||
| uses: ./.github/actions/get_channel_config/ | ||
| with: | ||
| config_file: ${{ env.CONFIG_FILE }} | ||
| channel: ${{ inputs.channel }} | ||
|
|
||
| # Only the binary matters here; this job's own bundled resources are | ||
| # discarded, so skip signing/notarization and the (otherwise mandatory) | ||
| # schema, both of which belong to the packaging step below. | ||
| - name: Build ${{ matrix.arch }} binary | ||
| id: build_tui | ||
| run: | | ||
| script/bundle --channel $CHANNEL --arch ${{ matrix.arch }} --artifact tui --nosign | ||
| shell: bash | ||
| env: | ||
| CHANNEL: ${{ steps.get-config.outputs.channel }} | ||
| GIT_RELEASE_TAG: ${{ needs.prepare_release.outputs.release_tag }} | ||
| NO_LICENSES: "1" | ||
| SKIP_SETTINGS_SCHEMA: "1" | ||
|
|
||
| # binary_path is already copied out of the per-target-triple Cargo output | ||
| # directory; --skip-build (used by release_macos_tui below) re-derives | ||
| # that copy from the triple directory, so preserve it here instead. The | ||
| # dSYM Cargo produces there is itself a symlink into target/.../deps, so | ||
| # (as with the app archive above) also include its resolved target; | ||
| # otherwise the link dangles once extracted into a fresh job. | ||
| - name: Create tar archive with build artifacts | ||
| run: | | ||
| BINARY_PATH="${{ steps.build_tui.outputs.binary_path }}" | ||
| PROFILE_DIR="${BINARY_PATH#target/}" | ||
| PROFILE_DIR="${PROFILE_DIR%/bundle/osx/*}" | ||
| RAW_BINARY_PATH="target/${{ steps.build_tui.outputs.rust_target }}/$PROFILE_DIR/$(basename "$BINARY_PATH")" | ||
| RAW_DSYM_PATH="$RAW_BINARY_PATH.dSYM" | ||
| TAR_PATHS=("$RAW_BINARY_PATH") | ||
| if [[ -e "$RAW_DSYM_PATH" ]]; then | ||
| TAR_PATHS+=("$RAW_DSYM_PATH") | ||
| if [[ -L "$RAW_DSYM_PATH" ]]; then | ||
| REAL_DSYM_PATH="$(python3 -c 'import os,sys; print(os.path.relpath(sys.argv[1]))' "$(realpath "$RAW_DSYM_PATH")")" | ||
| TAR_PATHS+=("$REAL_DSYM_PATH") | ||
| fi | ||
| fi | ||
| tar czfv build-artifacts.tar.gz "${TAR_PATHS[@]}" | ||
| shell: bash | ||
|
|
||
| - name: Archive ${{ matrix.arch }} TUI build artifacts | ||
| uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 | ||
| with: | ||
| name: macos-tui-${{ matrix.arch }}-${{ steps.get-config.outputs.channel }} | ||
| retention-days: 1 | ||
| # We compress the tar archive, so no need to re-compress. | ||
| compression-level: 0 | ||
| path: build-artifacts.tar.gz | ||
|
|
||
| release_macos_tui: | ||
| name: Build Release (macOS TUI ${{ matrix.arch }}) | ||
| runs-on: macos-26-xlarge | ||
| needs: [prepare_release, release_macos_single_arch, build_macos_tui_binaries] | ||
| if: ${{ inputs.build_macos != false }} | ||
| timeout-minutes: 60 | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| include: | ||
| - arch: aarch64 | ||
| - arch: x86_64 | ||
| steps: | ||
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6 | ||
|
|
||
| - uses: ./.github/actions/prepare_environment | ||
| with: | ||
| target_os: macos | ||
| is_self_hosted: false | ||
| ref: ${{ needs.prepare_release.outputs.release_branch }} | ||
| install_release_deps: true | ||
| ssh_key: ${{ secrets.WARP_CHANNEL_CONFIG_ACCESS_SSH_KEY }} |
vorporeal
marked this pull request as ready for review
August 23, 2026 00:38
Co-Authored-By: Warp <agent@warp.dev>
… and fix Cargo.toml spacing - script/run-tui: skip settings schema generation for local TUI runs, since the TUI binaries don't implement dump-settings-schema (only the full app binary does) and packaged TUI builds consume a schema generated from that binary during release instead. This fixes a regression where every local ./script/run-tui invocation failed with "Set SETTINGS_SCHEMA_EXECUTABLE or SETTINGS_SCHEMA_SOURCE" after prepare_bundled_resources started failing closed. - script/test_prepare_bundled_resources: add coverage for the SKIP_SETTINGS_SCHEMA=1 path that script/run-tui now relies on. - .github/workflows/create_release.yml: document why the macOS aarch64/x86_64 settings schema comparison expects byte-identical output. - app/Cargo.toml: collapse the double blank line left behind by removing the generate_settings_schema [[bin]] block.
Review found that script/run-tui's SKIP_SETTINGS_SCHEMA=1 silently disabled the bundled modify-settings skill for local TUI sessions (SkillManager gates it on resources/settings_schema.json existing). warp_tui already links the shared warp crate with its full default feature set to build at all, so generating the schema from the just-built TUI binary itself costs nothing extra: - Expose settings::dump_settings_schema as pub (was pub(crate)) so warp_tui can call it directly. - Add a dump-settings-schema [output_path] subcommand to the TUI's own CLI (crates/warp_tui/src/session.rs), mirroring warp_cli::Command::DumpSettingsSchema's shape, dispatched before the normal TUI bootstrap. - script/run-tui now points SETTINGS_SCHEMA_EXECUTABLE at the binary it just built instead of skipping schema generation. - Add script/test_run_tui_settings_schema: builds warp-tui-oss, checks it implements dump-settings-schema directly, and confirms the prepared resources satisfy modify-settings' exact activation gate. Packaging is untouched: release TUI packages still consume the canonical app-generated schema, and this local dev-only producer never enters the release path, so no schema-parity checks are needed. Also corrects the PR description bullet that said TUI binaries don't implement dump-settings-schema; that was incidental (TUI binaries parse their own CLI args rather than warp_cli::Command), not policy.
This PR made release_macos_tui, release_linux_tui, and release_windows_tui wait on the job that produces their platform's canonical schema (release_macos_single_arch, release_linux_x86, build_windows_binaries respectively). Those jobs previously needed only prepare_release, so this serialized the TUI build+notarize/package phase behind the (slower) app build phase, undoing the parallelism the release pipeline relied on. Split each into a build-only job (needs: prepare_release, builds the raw TUI binary, no schema/signing) and the existing release_*_tui job trimmed to packaging only (signs/notarizes/packages using the schema and the binary handed off from the build job). This mirrors the build_windows_binaries -> release_windows split already used for the GUI Windows binary: - macOS: new build_macos_tui_binaries (per arch) builds with --nosign, NO_LICENSES=1, SKIP_SETTINGS_SCHEMA=1, and uploads the binary+dSYM from their per-target-triple Cargo path. release_macos_tui now downloads that artifact and packages with --skip-build. - Linux: new build_linux_tui_binaries (per arch, native runners) builds with NO_LICENSES=1, SKIP_SETTINGS_SCHEMA=1, and uploads the binary. release_linux_tui downloads it and packages with --skip-build. - Windows: new build_windows_tui_binaries builds with -skip_build_installer (already schema-free) and uploads the binary+pdb. release_windows_tui downloads it and locates the same outputs via -skip_build_binary -skip_build_installer (the same locate idiom release_windows already uses) before signing and packaging. release_linux_arm is intentionally left alone: it builds nothing it can execute (consumes pre-built artifacts from build_linux_arm_binaries / build_linux_cli_arm_binaries), so it must keep waiting on release_linux_x86 for the schema regardless. No packaging behavior, published artifact, or the fail-closed SETTINGS_SCHEMA_EXECUTABLE/SOURCE contract changed -- only when each half of the split runs and what it waits on.
… dSYM symlink Both were artifact-handoff bugs from the build/package split in 30771d4: - Linux: the build job archived executable_path, which script/linux/bundle already reports as the staged target/<profile>/bundle/linux/<bin> copy. But --skip-build (used by release_linux_tui) still unconditionally cp's from the raw target/<profile>/<bin> Cargo output before staging it again, and that raw path was never in the archive. Archive the raw path instead, derived from debug_executable_path (raw path + ".debug") so we don't have to duplicate the channel/profile-naming logic that lives in the script. - macOS: the build job archived the raw per-triple dSYM as a bare path. Cargo's dSYM there is a symlink into target/.../deps, so once extracted in a fresh packaging job the link dangled and the dwarfdump/sentry-cli verification in release_macos_tui failed. Also archive the symlink's resolved target (as a relative path), mirroring the existing app artifact's binary_path/dsym_path/dsym_realpath pattern. Verified both fixes locally with tar archive/extract simulations in a separate directory, confirming the raw Linux binary path is restored and the macOS dSYM symlink resolves (non-dangling) post-extraction. Swept the rest of each TUI packaging job for the same class of assumption (a path resolving into target/ that must survive the new build/package artifact boundary): - macOS: only the binary and dSYM are read from target/ in the tui branch of script/macos/bundle; both are now covered. Codesigning/notarization operate on the OUT_DIR copy created fresh in the packaging job itself. - Linux: only the executable path is read from target/ for the tui artifact; now covered. prepare_bundled_resources and the tarball validation step operate on the OUT_DIR copy created fresh in the packaging job. - Windows: already used direct actions/upload-artifact and actions/download-artifact on the script's own absolute-path outputs (binary_path, pdb_file_path), matching the existing build_windows_binaries -> release_windows handoff exactly, so this class of bug does not apply there. actionlint diagnostic count is unchanged (17, same pre-existing custom-runner-label and unrelated action-metadata noise as before this commit) -- no new issues introduced.
… targets A live release run failed: build_linux_cli_arm_binaries cross-compiles an aarch64 CLI binary on an x86_64 runner and set no SETTINGS_SCHEMA_SOURCE/SETTINGS_SCHEMA_EXECUTABLE, so script/linux/bundle defaulted to executing the just-built aarch64 binary on the x86_64 host to generate its settings schema, failing with an exec format error. Specific fix: skip schema generation in build_linux_cli_arm_binaries via SKIP_SETTINGS_SCHEMA=1 - release_linux_arm, which packages this binary, always supplies its own SETTINGS_SCHEMA_SOURCE, so this job never needs one. General hardening: script/linux/bundle, script/macos/bundle, and script/windows/bundle.ps1 all default SETTINGS_SCHEMA_EXECUTABLE to the just-built binary when unset, assuming it's executable on the host. Compute whether the host can actually execute the target architecture (accounting for Rosetta 2 on macOS and Windows' arm64-host x64-emulation) and fail with a clear error instead of defaulting blindly when it can't. script/windows/prepare_bundled_resources.ps1 was already fail-closed with no such default, so it needed no change.
script/macos/bundle: uname -m reports the running process's architecture, not the hardware. In a Rosetta-translated x86_64 shell on Apple Silicon it reports x86_64, which made the new cross-compile guard reject --arch aarch64 CLI/warpctrl/TUI builds that would actually succeed. Check hw.optional.arm64 first, which reflects the real hardware. script/windows/bundle.ps1: similarly, PROCESSOR_ARCHITECTURE reports AMD64 for an x64 process running under WOW64 on a Windows-on-ARM host. PROCESSOR_ARCHITEW6432 carries the true native host architecture in that case, so prefer it when present.
…ackaging-only jobs Both jobs serialized their (slow, notarize/codesign- or gpg-signing-heavy) build behind release_macos_single_arch / release_linux_x86 respectively, even though they only need the canonical settings schema those jobs produce, not their binaries. Split each into a build-only job (needs only prepare_release) and a trimmed packaging job that downloads the build artifact and the canonical schema, mirroring the build_*_tui_binaries / release_*_tui split already established for the TUI jobs. - build_macos_cli_binaries builds with --nosign and SKIP_SETTINGS_SCHEMA=1; release_macos_cli downloads it and runs --skip-build with the real schema and signing secrets. Preserves both the raw-vs-staged binary_path distinction and the dSYM symlink target when archiving, per the same class of bug fixed for the TUI split. - build_linux_cli_x86_binaries builds with --packages none and SKIP_SETTINGS_SCHEMA=1; release_linux_cli_x86 downloads it and runs --skip-build with the real schema. Unlike the TUI job, the cli artifact's executable_path/debug_executable_path are already raw target/ paths (no staging), so no raw-vs-staged derivation is needed here.
gate_tui_release_artifacts only existed because the TUI jobs were never added to generate_changelogs' own needs list; it also treated a deliberately skipped platform (build_macos=false, build_linux=false, or web on the preview channel) the same as a genuine failure, since it compared job results directly to 'success' with no notion of 'this platform was never supposed to run'. Replace it with collect_results, which aggregates every build/release job (TUI and non-TUI alike) into one place: - if: always() so it still runs, and still reports failures, when any of its dependencies did not succeed. - A platform disabled via a workflow input is excluded outright, regardless of its (necessarily 'skipped') result. Any other non-'success' result -- a genuine failure, a cancellation, or a job skipped because one of its own dependencies (e.g. a build-only job) failed -- counts as a failure. - The job itself fails when there is a genuine failure, which is the publish gate: generate_changelogs needs collect_results with default (success-required) semantics, so it is skipped whenever collect_results fails, same as any other failed dependency. should_publish is still independently honored via generate_changelogs' own if: condition. - The failure list is exposed as a job output that send_slack_notif_if_unsuccessful now consumes directly, instead of recomputing it from a second, separately-maintained list of the same jobs. That job keeps if: always() so it can still report on a collect_results failure. The existing web-failure-ignored-on-preview special case, and the exact user-visible failure-name strings, are preserved. generate_changelogs' needs list collapses from nine individual job dependencies plus gate_tui_release_artifacts down to prepare_release (for its release_tag/release_branch/should_publish outputs) and collect_results (the sole success/failure gate).
collect_results passed a literal false for both Windows leaf jobs' disabled flag instead of deriving it from inputs.build_windows the same way as build_macos/build_linux/build_web. With Windows disabled, both Windows release jobs are correctly skipped by their own if:, but collect_results treated that skip as a genuine failure, failed the job, and blocked generate_changelogs (plus fired a false Slack notification) for an otherwise-publishable partial-platform release. The complete set of disable inputs enumerated from the workflow's own workflow_call/workflow_dispatch inputs blocks: build_linux, build_windows, build_macos, build_web. (should_publish is a separate publish gate, not a per-platform disable switch.) All four are now represented.
…ad params Six items from David's review pass: - Removed the 'Setup Go' step from the two new build-only jobs (build_macos_cli_binaries, build_macos_tui_binaries). It was copied wholesale from the packaging jobs they were split off from, but nothing in the actual build path (cargo build, prepare_bundled_resources) needs a Go toolchain. Left the packaging jobs' pre-existing Setup Go steps alone, since those predate this PR's TUI/CLI split work. - Rewrote five 'Builds the X binary only, with no dependency on <job>, so ...' comments (build_macos_cli_binaries, build_macos_tui_binaries, build_linux_tui_binaries, build_linux_cli_x86_binaries, build_windows_tui_binaries) to drop the defensive 'no dependency on' framing while keeping the actual rationale (packaging happens in a separate job so the build can run in parallel instead of serializing). - Added a blank line between two steps in build_windows_tui_binaries that were missing one. - Removed the unused cargo_profile parameter from script/prepare_bundled_resources (and its Windows PowerShell counterpart): the value was accepted and stored but never read anywhere in either script. Its doc comment claimed it was 'retained for compatibility with existing callers' without naming them; the real callers (script/linux/bundle, script/linux/bundle_install, script/macos/bundle x3, script/windows/bundle.ps1) do exist, but since the parameter does nothing on the receiving end, updated all of them to stop passing it instead of keeping a misleading claim. - Deleted script/test_run_tui_settings_schema. It requires a full cargo build (several minutes) to prove two things: that warp-tui-oss wires up its dump-settings-schema subcommand to the same function schema_generation_tests.rs already unit-tests, and that the resulting schema activates the modify-settings skill -- which reduces to checking settings_schema.json exists, already exercised (with a fake executable) by script/test_prepare_bundled_resources's SETTINGS_SCHEMA_EXECUTABLE case. It isn't wired into presubmit or any CI workflow. The one-time verification it was added for has already happened; the cost of keeping it running (and its real-build dependency) outweighs the thin, mostly redundant regression coverage it provides. - Kept script/test_prepare_bundled_resources: it directly exercises the core branching contract of prepare_bundled_resources (the SETTINGS_SCHEMA_EXECUTABLE / SETTINGS_SCHEMA_SOURCE / SKIP_SETTINGS_SCHEMA paths and their mutual-exclusivity and missing-input failure modes) that this PR's cross-compile and host-detection fixes have repeatedly touched, at near-zero cost (no real build, self-contained fake executable). - Added a brief comment on release_linux_tui (previously the only packaging job in the split with no comment of its own) explaining why it exists as a separate job from build_linux_tui_binaries. Verified: actionlint 18 findings, unchanged; ./script/format --check clean; bash -n on all touched shell scripts; PowerShell parser confirms no syntax errors in both touched .ps1 files; ./script/test_prepare_bundled_resources still passes after the cargo_profile parameter removal.
…plit comments The cargo_profile arity change in 074ad8a missed three callers because the sweep grepped for the parameter name on a single line rather than counting every call site's actual argument count: - script/run-tui's prepare_tui_bundled_resources branched on $PROFILE_DIR = debug, and only the else branch (any non-debug profile, e.g. --release) passed a third positional argument. That branch now dies immediately with 'Expected 1-2 arguments but received 3' on the exact path that isn't exercised by a plain debug run. Since the parameter is gone, both branches are identical now, so the if/else collapses to a single call. - script/deploy_remote_server and script/deploy_remote_server_to_test_vm both still passed "$CARGO_PROFILE" as a third argument on its own continuation line, which the earlier single-line grep for 'prepare_bundled_resources.*CARGO_PROFILE' never matched. - flake.nix's Nix build script passed a literal 'release' as a third argument, for the same reason. Verified the run-tui fix for real, not just by reasoning about it: freed space on the build cache volume (it was at 100%, unrelated to this change, from accumulated incremental build artifacts), built the real warp-tui-oss release binary, then ran the exact SETTINGS_SCHEMA_EXECUTABLE + 2-argument prepare_bundled_resources invocation the now-unified prepare_tui_bundled_resources performs for a non-debug profile against that real binary, and confirmed it generates a valid settings_schema.json. Also tightened the build/package split comments per feedback that they were still too long and, for the Linux TUI pair, explained the same split twice from both sides. Each pair now gets exactly one 1-2 line comment on the packaging job (release_macos_cli, release_macos_tui, release_linux_tui, release_linux_cli_x86, release_windows_tui), stating only what's packaged here and where the binary came from; the build-only jobs are no longer separately commented, and the 'mirroring the X / Y split' tails are gone from all five. Re-audited every prepare_bundled_resources / prepare_bundled_resources.ps1 caller by argument count rather than by name: script/macos/bundle (x3), script/linux/bundle, script/linux/bundle_install, script/windows/bundle.ps1, script/macos/run, script/test_prepare_bundled_resources, script/test_factory_files_skill.py, script/run-tui, script/deploy_remote_server, script/deploy_remote_server_to_test_vm, and flake.nix -- all now pass at most 2 positional arguments (or the .ps1 equivalent), matching what both scripts accept.
The comment justifying the SKIP_SETTINGS_SCHEMA=1 test case said local TUI binaries don't implement dump-settings-schema. That was true when written, but this PR added that subcommand to the TUI binaries themselves (crates/warp_tui/src/session.rs) and script/run-tui now calls it, so the comment is a false explanation left behind by a capability change it predates. The flag itself is still genuinely exercised elsewhere (script/macos/run, script/linux/test_bundle_warpctrl, and the release workflow's build-only jobs all set it to defer schema generation to a later packaging step), so the test case stays; only the justification was wrong. Replaced it with that real reason, kept to one line. Swept every comment this PR touched or added, across the workflow, the bundle/deploy scripts, and the Rust settings/CLI code, for the same kind of staleness against the now-final TUI schema capability. Found nothing else: script/run-tui's own function comment, the DumpSettingsSchema doc comments in crates/warp_tui and crates/warp_cli, the macOS/Linux cross-arch schema comparison caveats, and the PR description's TUI bullet all already describe the current, post-iteration state accurately. bash -n and a re-run of script/test_prepare_bundled_resources both pass.
build_windows_tui_binaries uploaded binary_path and pdb_file_path directly. Both live in the same target/<triple>/<profile> directory, so actions/upload-artifact collapsed the least common ancestor to that directory and stripped the prefix. release_windows_tui downloaded with path: ., landing the exe at the workspace root, while its own script/bundle invocation (--skip_build_binary --skip_build_installer) recomputes binary_path as the full target/... path. The Trusted Signing step then failed with 'File not found' on a real release run -- the app asset DLLs signed fine, only the TUI binary was missing. The pre-existing app flow (build_windows_binaries / release_windows) doesn't hit this because it uploads a third, workspace-relative path (app/assets/windows/<arch>) alongside the same-directory binary_path/ pdb_file_path pair. That third path drags the LCA up to the workspace root, which preserves the full relative structure for every file in the artifact -- an accidental property of which paths happen to be listed, not a guarantee. The Windows TUI split copied the two-path shape without that accidental third path, so it lost the guarantee. Fixed by tar-ing with explicit relative paths, the same approach already used for every macOS/Linux split job in this PR: convert the Windows absolute path to POSIX with cygpath -u, compute it relative to the job's cwd with realpath, then tar/extract that. This makes the preserved structure an explicit property of the archive contents rather than an emergent property of upload-artifact's LCA algorithm. Verified the realpath+tar+extract chain directly (not just by reasoning): simulated the exact target/<triple>/<profile>/<binary+pdb> layout in an isolated directory, ran the same realpath --relative-to and tar/extract commands the workflow now runs, and confirmed both files land back at the identical relative path a fresh consumer's script/bundle invocation expects. cygpath -u's Windows-path-to-POSIX translation itself is a standard, long-established git-bash utility I could not exercise directly in this (Linux) environment, since no Windows runner was available to me. Audited every upload/download artifact pair introduced by this PR's platform splits, per the specific question of whether the structure its consumer resolves is guaranteed or incidental: - macOS CLI (build_macos_cli_binaries -> release_macos_cli): guaranteed. Uploads a single build-artifacts.tar.gz; the internal layout is set entirely by the paths passed to , so upload-artifact's LCA computation over a one-element path list never enters into it. - macOS TUI (build_macos_tui_binaries -> release_macos_tui): guaranteed, same reasoning. - Linux CLI x86_64 (build_linux_cli_x86_binaries -> release_linux_cli_x86): guaranteed, same reasoning (paths made relative via realpath before tar-ing). - Linux TUI (build_linux_tui_binaries -> release_linux_tui): guaranteed, same reasoning. - Windows TUI (build_windows_tui_binaries -> release_windows_tui): was incidental (relied on the two paths happening to share a directory in a way that made the bug latent rather than immediate); now guaranteed via the same tar approach. actionlint: 18 findings, unchanged.
vorporeal
force-pushed
the
david/optimize-settings-schema-generation-during-release
branch
from
August 23, 2026 00:38
fa13404 to
bc4e29c
Compare
Contributor
|
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 Powered by Oz |
![warp-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR moves settings schema generation into the shipped Warp executables and rewires release packaging to pass canonical schema artifacts through the macOS, Linux, and Windows jobs.
Concerns
- The Windows TUI binary-only job invokes the updated bundler without a schema input or
SKIP_SETTINGS_SCHEMA, so it will fail before uploading the binary artifact. - The Windows TUI packaging job's locate-only bundler invocation also omits a schema input despite using
--skip_build_binary, so it will fail before installer packaging can proceed. - The Windows app packaging job's locate-only bundler invocation likewise omits a schema input despite using
-skip_build_binary, so signing/package steps cannot run.
Verdict
Found: 0 critical, 3 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
|
|
||
| - name: Build Warp Agent CLI | ||
| id: build_tui | ||
| run: script/bundle --artifact tui --channel "$CHANNEL" --skip_build_installer --arch ${{ matrix.arch }} |
Contributor
There was a problem hiding this comment.
script/windows/bundle.ps1, whose new fail-closed check rejects TUI bundles unless a schema input or SKIP_SETTINGS_SCHEMA=1 is set; add the skip env here like the macOS/Linux binary jobs or the artifact upload will never run.
Contributor
There was a problem hiding this comment.
Not a defect: this invocation passes --skip_build_installer, and script/windows/bundle.ps1 returns at the $SKIP_BUILD_INSTALLER block (emitting binary_path/pdb_file_path, then exit 0) before it ever reaches the schema check further down. No schema input is needed here.
Responding as wilson: Open session · View in factory
| - name: Locate TUI binary build outputs | ||
| id: build_tui | ||
| run: script/bundle --artifact tui --channel "$CHANNEL" --skip_build_installer --arch ${{ matrix.arch }} | ||
| run: script/bundle --artifact tui --channel "$CHANNEL" --skip_build_binary --skip_build_installer --arch ${{ matrix.arch }} |
Contributor
There was a problem hiding this comment.
--skip_build_binary but does not pass the downloaded schema or set SKIP_SETTINGS_SCHEMA=1, so the updated Windows bundler exits before exposing steps.build_tui.outputs.
Contributor
There was a problem hiding this comment.
Not a defect: same reason as the build job. This passes --skip_build_installer, so bundle.ps1 exits 0 from the $SKIP_BUILD_INSTALLER block after emitting its outputs, well before the schema check. The step that does need a schema — "Bundle signed Warp Agent CLI installer", which omits --skip_build_installer — correctly sets SETTINGS_SCHEMA_SOURCE. Corroborated by a real release run, which reached the signing step with binary_path resolved.
Responding as wilson: Open session · View in factory
|
|
||
| - name: Locate binary build outputs | ||
| id: binary_paths | ||
| run: script/bundle -Channel $CHANNEL -skip_build_binary -skip_build_installer --arch ${{ matrix.arch }} |
Contributor
There was a problem hiding this comment.
-skip_build_binary without a schema env, which now hits the new -skip_build_binary requires SETTINGS_SCHEMA_SOURCE or SETTINGS_SCHEMA_EXECUTABLE branch before signing can run.
Contributor
There was a problem hiding this comment.
Not a defect: this also passes -skip_build_installer, so bundle.ps1 returns from the $SKIP_BUILD_INSTALLER block before the schema check. The fail-closed branch is only reachable on invocations that go on to prepare bundled resources.
Responding as wilson: Open session · View in factory
![warp-agent-staging[bot]](https://avatars.githubusercontent.com/in/2196476?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
Moves settings-schema generation into the shipped executables and reworks the release pipeline's job graph and artifact handoffs. Approving at the author's request.
What this approval is, and isn't
Disclosure: the factory authored 13 of the 16 commits on this branch, so this is not an independent review of most of the diff. The independent signal that does exist:
- A reviewer with no exposure to this PR's history went over it cold and returned a single finding, since fixed.
- All CI checks pass on every platform.
- The three
Request changesfindings fromwarp-for-osswere each checked against the code and refuted in their threads: all three invocations pass--skip_build_installer, sobundle.ps1returns from the$SKIP_BUILD_INSTALLERblock before reaching the fail-closed schema check.
Not covered
The full release workflow has not been run end to end against this head. Earlier runs against earlier commits surfaced two real failures — the cross-compiled ARM CLI exec-format error and the Windows TUI artifact path stripping — both fixed since.
Verdict
Checks: build pass, tests pass, CI green, visual proof n/a
Found: 0 critical, 0 important, 0 suggestions, 0 nits
Responding as wilson: Open session · View in factory
vorporeal
deleted the
david/optimize-settings-schema-generation-during-release
branch
August 23, 2026 01:21
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Problem
The release pipeline generated
settings_schema.jsonwith a separategenerate_settings_schemaCargo binary. PR #12884 gave that binary the application feature set so that it generated an accurate schema.On macOS, the feature set enabled dynamic Sentry framework linkage. The release job ran the generator outside the application bundle. The binary had no runtime search path for the bundled framework, so
dyldcould not loadSentry.framework.A framework search path would fix that immediate error, but it would not fix the release design. Packaging-only and cross-target jobs would still compile and link a separate Warp binary only to generate the schema. That work adds release time and can generate a schema with the wrong channel or feature state.
Approach
This PR moves schema generation into the main Warp executable:
warp dump-settings-schema [output-path]generates the schema with the executable's initialized channel and feature flags.dump-settings-schemafor local development. Packaged TUI jobs still consume the canonical application-generated schema. Each public setting has anx-warp-surfacesannotation that identifies its GUI and TUI surfaces.SETTINGS_SCHEMA_EXECUTABLEorSETTINGS_SCHEMA_SOURCE.The standalone generator binary and its separate Cargo target are removed.
Alternatives considered
Set
DYLD_FRAMEWORK_PATHfor the standalone generatorThis change would fix the immediate macOS launch error. It would keep the separate generator build and would not help cross-target or packaging-only jobs.
Remove
cocoa_sentryor use a reducedstandalonefeature setThis change would avoid the dynamic framework dependency. It would also create a different Cargo unit and could generate a schema that does not match the shipped application feature set.
Revert the feature-set parity change
This change would restore the old release behavior, but it would also restore the schema mismatch that PR #12884 tried to remove.
Move the generator to a separate crate
A separate crate does not help if it still links the Warp dependency graph. It would still require another compilation and link step.
Build the generator with the initial Cargo command
This change would remove the later Cargo command, but the generator would remain a separate binary target. It would also not solve the cross-target packaging case.
Add dedicated schema producer jobs
A dedicated job would reduce dependencies between packaging jobs. It would also build Warp only to generate a schema. This PR instead reuses the native production executables that the release already builds.
Add metadata and hash sidecar files
Sidecar files could improve diagnostics and support artifact reuse across workflow runs. This workflow uses same-run artifacts, explicit job dependencies, fail-closed resource inputs, and byte-for-byte architecture comparisons. Those controls are sufficient for this change. Sidecar files can be added if the workflow later reuses schemas across runs.
Linked Issue
There is no linked issue. This PR addresses a release failure introduced after PR #12884.
ready-to-specorready-to-implement. Not applicable.Testing
./script/format --checkcargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warningscargo clippy -p warp --all-targets --tests -- -D warningscargo clippy -p warp_completer --all-targets --tests -- -D warningscargo nextest run -p warp -E 'test(schema_generation)'cargo check -p warp --bin warp-oss --features release_bundle,guicargo check -p warp_tui --bin warp-tui-oss --features release_bundle,standalonescript/test_prepare_bundled_resourcesactionlintfor.github/workflows/create_release.yml.github/actions/bundle_arch_package/action.yml./script/run. This check is not applicable because this PR does not change interactive application behavior.An end-to-end release workflow run is still required to validate package publication and cross-job artifact transfer on all release platforms.
Agent Mode
CHANGELOG-NONE
Co-Authored-By: Warp agent@warp.dev