Add temporary manual macOS-15-large workflow for M4 compatibility diagnostics

[Copilot]

This PR adds a temporary GitHub Actions workflow to reproduce and diagnose the app’s M4-specific failure path without affecting existing CI triggers. It mirrors the current macOS Tauri release flow, then layers in backend test execution and artifacted diagnostics for root-cause analysis.

• Scope: temporary M4-only diagnostic workflow

  • Added .github/workflows/m4-test.yml
  • Trigger is workflow_dispatch only (no push/PR/scheduled coupling)
  • Runner is pinned to macos-15-large (Apple M4 Pro)

• Parity with existing macOS release build path

  • Reuses the same core macOS setup/build sequence from tauri-multi-build.yml:
    • checkout
    • Node 24 setup + npm install in genhat-desktop
    • stable Rust toolchain
    • model placeholder scaffolding
    • npx tauri build --bundles dmg

• Additional diagnostics for M4 investigation

  • Adds explicit Rust backend test execution: cargo test --lib (genhat-desktop/src-tauri)
  • Captures environment/toolchain fingerprint (sw_vers, CPU model, node/npm/rust/cargo/tauri versions)
  • Persists logs and bundle tree as artifacts (m4-compatibility-logs) even on failure

• Workflow hardening

  • Explicit minimal token permissions (contents: read)
  • Diagnostics step avoids shell xtrace to reduce accidental log overexposure

on:
  workflow_dispatch:

jobs:
  m4-compatibility:
    runs-on: macos-15-large
    permissions:
      contents: read
    steps:
      - run: cargo test --lib 2>&1 | tee "$RUNNER_TEMP/cargo-test-m4.log"
      - run: npx tauri build --bundles dmg 2>&1 | tee "$RUNNER_TEMP/tauri-build-m4.log"
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: m4-compatibility-logs

Original prompt

Create a temporary GitHub Actions workflow to test the application on Apple M4 hardware (macos-15-large runner) to identify why the app works on M3 but fails on M4.

The temporary workflow should:

1. Run on a manual trigger (workflow_dispatch) so it doesn't interfere with existing CI
2. Test on macos-15-large (M4 Pro runner)
3. Run the same build steps as the existing tauri-multi-build.yml workflow for macOS
4. Build and test the Rust backend (cargo test)
5. Build the Tauri app for macOS to capture any build or runtime errors
6. Provide detailed logs to diagnose the M4 compatibility issue

This is a temporary workflow to help identify the root cause before deciding whether permanent M4-specific CI changes are needed.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Is there a reason why this application is working fine on apple M3 but not on M4? Do i need to fix my CI jobs to support M4 separately?

Assistant: I'll help you investigate why your application might be working differently on Apple M3 versus M4. Let me first explore the repository to understand its structure, language composition, and CI configuration.

Assistant: Let me search for CI/CD configuration files and investigate the build setup:

Assistant: Based on my investigation of your repository, here's what I found:

Short Answer

In most cases, you don't need separate CI jobs for M4, but there can be compatibility issues. The key issue isn't the hardware itself (both M3 and M4 are ARM-based Apple Silicon)—it's more likely related to:

1. macOS version differences - M4 ships with newer macOS versions that may have API deprecations or stricter validation
2. ONNX Runtime issues - Your app uses ort (ONNX Runtime) with download-binaries feature, which may have M4-specific versions or binary compatibility problems
3. Dependency/library updates - System libraries or build dependencies may behave differently

Your Current CI Setup

Your workflows use macos-latest runner, which automatically targets the latest macOS on M3/M4 hardware. This is actually good—you're not hardcoding architectures.

What to Check First (Before Adding M4-Specific Jobs)

1. Test locally on M4: Get the exact error message. Is it a runtime crash, build failure, or functional bug?

2. Check ONNX Runtime compatibility: Your Cargo.toml includes:

   ort = { version = "2.0.0-rc.11", features = ["download-binaries", "coreml"] }

   The download-binaries feature auto-fetches pre-built binaries. Verify that 2.0.0-rc.11 has M4 arm64 builds. You might need to upgrade to a stable version.

3. Run on GitHub's M4 runners: GitHub now offers macos-14-large (M3 Pro) and macos-15-large (M4 Pro) runners. Test your build on both to see which fails.

4. Check your Rust toolchain: Ensure you're using a recent stable Rust that fully supports Apple Silicon.

Recommended Action

Don't add separate CI jobs yet. Instead:

• Add a test run on macos-15-large runner temporarily to identify the exact failure
• If it fails, debug the root cause (likely ONNX Runtime or dependency version)
• Once fixed, remove the temporary test job

If the issue is a genuine hardware incompatibility (very unlikely with ARM), then add separate M3/M4 matrix jobs. But 95% of the time, it's a software/dependency issue that a single fix solves for both architectures.

User: Can you create a test runner for M4 temporarily?

Assistant: I've created a temporary M4 test runner for you. The workflow is set up as a manual trigger so it won't interfere with your existing CI jobs.

What the new workflow does:

✅ Triggers manually via workflow_dispatch (no automatic runs)
✅ Runs on macos-15-large (GitHub's M4 Pro runner)
✅ Performs the same Rust backend tests and Tauri builds as your production workflow
✅ Includes detailed logging to capture build errors and failures
✅ Tests both the Rust test suite and the full macOS app build

How to use it:

1. Go to Actions → M4 Compatibility Test (or find it in the workflow list)
2. Click Run workflow → select main branch → Run workflow
3. Wait for the job to complete and check the logs for any M4-specific errors

To delete it later:

Once you've identified and fixed the issue, just delete .github/workflows/m4-test.yml and commit the deletion.

The workflow will help you identify if the issue is in the build process, ONNX Runtime binaries, Tauri compilation, or something else—then you'll know exactly what needs to be fixed!

This pull request was created from Copilot chat.

[Amoghk04]

Only for testing, delete it soon after

[Copilot]

Pull request overview

Adds a manual-only GitHub Actions workflow to reproduce and diagnose macOS 15 (Apple M4 Pro) build/test failures without impacting existing CI triggers, largely mirroring the current macOS Tauri release build path while collecting logs as artifacts.

Changes:

• Introduces a workflow_dispatch-only “Temporary M4 Compatibility Test” job pinned to macos-15-large.
• Reuses the macOS Tauri build setup pattern (checkout, Node 24 install, Rust stable, model placeholder scaffolding, Tauri dmg build).
• Adds Rust backend test execution plus log/artifact collection for diagnostics.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.