ci: require native macOS build and tests after existing runner jobs

This commit is contained in:
dh
2026-10-03 17:12:28 +02:00
parent b19dbd21a7
commit cfe8c13f4a
3 changed files with 34 additions and 6 deletions
@@ -131,6 +131,34 @@ jobs:
find MeetingAssistant.Tests -type d -name TestResults -print || true
find MeetingAssistant.Tests -type f -path "*/TestResults/*" -maxdepth 5 -print || true
macos-native-full:
needs: [build-and-test, portable-build-and-test]
runs-on: ubuntu-latest
timeout-minutes: 180
env:
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: "1"
DOTNET_NOLOGO: "1"
steps:
- name: Checkout exact native CI candidate
uses: actions/checkout@v7
- name: Setup .NET orchestration SDK
uses: actions/setup-dotnet@v6
with:
dotnet-version: "10.0.x"
- name: Run owned software macOS guest and all native tests
run: dotnet run --file tools/ci/MacOsNativeDiagnostic.cs -- --run --full --output artifacts/native-macos-full
- name: Always remove only this run's owned resources
if: always()
run: dotnet run --file tools/ci/MacOsNativeDiagnostic.cs -- --cleanup --output artifacts/native-macos-full
- name: Retain native build, signatures, TRX and guest receipts
if: always()
uses: actions/upload-artifact@v3
with:
name: native-macos-full
path: artifacts/native-macos-full/
if-no-files-found: error
retention-days: 7
portable-build-and-test:
runs-on: ubuntu-latest
env:
+4 -4
View File
@@ -169,13 +169,13 @@ Detailed workflow syntax and extension guidance live in `docs/meeting-workflow-e
Behavior changes are OpenSpec-driven and test-first: update the relevant requirement/scenario, add a failing public behavior test, implement the smallest passing change, run focused tests and then the justified broader suite, and validate the active change with `openspec validate <change-id> --strict`. Documentation-only maintenance does not need a new OpenSpec change.
The Gitea workflow runs for pull requests, pushes, and manual dispatch on the existing `ubuntu-latest` runners. One job explicitly builds the Windows desktop target, installs Wine plus a matching Windows .NET SDK, and runs the portable test project through the Windows host under Wine. Another job builds and tests `net10.0` on Ubuntu, including the managed macOS audio, calendar, screenshot, registration, and desktop-control behavior tests. Its `TZ=Europe/Berlin` setting also exercises the calendar daylight-saving regression. No additional runner labels or host devices are required.
The Gitea workflow runs for pull requests, pushes, and manual dispatch on the existing `ubuntu-latest` runners. One job explicitly builds the Windows desktop target, installs Wine plus a matching Windows .NET SDK, and runs the portable test project through the Windows host under Wine. Another job builds and tests `net10.0` on Ubuntu, including the managed macOS audio, calendar, screenshot, registration, and desktop-control behavior tests. Its `TZ=Europe/Berlin` setting also exercises the calendar daylight-saving regression. After both jobs pass, the workflow requires a native macOS Full job on the same existing runner label. No additional runner labels or host devices are required.
Ubuntu does not compile the Swift helpers or execute Apple frameworks. Tests requiring the native macOS environment report an explicit skip through `MacOsFact`; they must also be run on a supported Mac with `dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0 -c Release -p:EnableWindowsTargeting=true`. That build compiles and signs the helpers, and the suite checks packaging, helper self-tests, and native image cropping. Real microphone/system-audio capture and privacy permissions still require the operational checks described above.
The Ubuntu managed-test job does not compile the Swift helpers or execute Apple frameworks; its native macOS tests report an explicit skip through `MacOsFact`. The prepared Full job runs an owned macOS 14+ x86_64 guest through unprivileged TCG on the existing Ubuntu Docker runner, builds and signs the native helpers, and requires all 577 tests to pass with zero skips, including all five native macOS tests. It has a 180-minute job limit with `always()` steps for retained evidence and ownership-checked cleanup. This CI path remains unqualified until an actual remote installed guest produces every required receipt. Native tests can also be run on a supported Mac with `dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0 -c Release -p:EnableWindowsTargeting=true`; real microphone/system-audio capture and privacy permissions still require the operational checks described above.
[Docker-OSX](https://github.com/sickcodes/Docker-OSX) runs a macOS VM rather than providing a Wine-style compatibility layer. Its launcher supports software emulation with `KVM=accel=tcg`, so KVM is not an absolute requirement. A supported .NET 10 guest needs macOS 14 or later plus the Swift build tools. The documented `auto` build downloads a preinstalled guest disk through `IMAGE_URL`; its documented ready-made tags and disk downloads were unavailable when checked on 2026-10-03. No verified native guest bootstrap is owned by this repository. CI validates source; it does not publish or deploy the workstation application.
The separate manual `.gitea/workflows/macos-native-full.yaml` retains the same Full flow as a diagnostic entry point. CI validates source; it does not publish or deploy the workstation application.
The separate manual [native Recovery diagnostic](docs/macos-native-diagnostic.md) probes macOS startup and disk readiness through an unprivileged TCG guest on the existing Ubuntu Docker runner. It neither installs macOS nor runs application tests; its result is a prerequisite for a future native test job, not verification of macOS CI support.
The separate manual [native Recovery diagnostic](docs/macos-native-diagnostic.md) probes macOS startup and disk readiness before qualifying the prepared Full flow. It neither installs macOS nor runs application tests. A green Recovery diagnostic alone does not verify macOS build/test CI support; each Full run repeats Recovery readiness for its own guest and disk.
## Operations And Limitations
+2 -2
View File
@@ -1,6 +1,6 @@
# Native macOS Recovery diagnostic on the existing Ubuntu runner
This manual diagnostic tests the unresolved Recovery startup boundary before adding a native macOS application test job. It does not install macOS, erase a guest disk, install .NET or Apple CLT, or run Meeting Assistant tests. A green diagnostic means only that a real macOS 14+ x86_64 Recovery guest has a working launchd system domain, DiskArbitration and exactly one writable 64-GiB guest disk.
This manual diagnostic tests the unresolved Recovery startup boundary before qualifying the prepared native macOS application build/test flow. It does not install macOS, erase a guest disk, install .NET or Apple CLT, or run Meeting Assistant tests. A green diagnostic means only that a real macOS 14+ x86_64 Recovery guest has a working launchd system domain, DiskArbitration and exactly one writable 64-GiB guest disk.
The workflow `.gitea/workflows/macos-native-diagnostic.yaml` has only `workflow_dispatch`; it does not run on ordinary pushes or pull requests. It uses the same `ubuntu-latest` label and existing Docker daemon as the current builds. There are no runner changes, extra host devices, privileged containers, added capabilities, published ports, host networking or new secrets. It fails clearly if the existing Docker daemon cannot fit its bounded resource budget.
@@ -36,7 +36,7 @@ The earlier background-only local bootstrap never obtained DiskManagement readin
## Experimental full guest flow
The separate `.gitea/workflows/macos-native-full.yaml` is also manual-only. Before a full attempt, inspect the candidate and its ownership boundaries and wait for the actual remote Recovery probe to qualify. The full acceptance review follows actual remote build/test verification. The full run repeats Recovery readiness in its own VM; it does not accept another run's disk receipt. The ordinary diagnostic workflow and checked-in read-only hook keep their read-only behavior.
The prepared `.gitea/workflows/pr-push-build-and-test.yaml` requires the `macos-native-full` job after both existing Wine and portable jobs succeed, using `ubuntu-latest`, a 180-minute limit and the same checkout/SDK/Full-run/always-cleanup/artifact steps as the separate manual `.gitea/workflows/macos-native-full.yaml`. The manual Full workflow remains a diagnostic entry point. This automatic CI path is unqualified until an actual remote installed guest provides the required native build and test receipts. Before publishing or attempting it, inspect the candidate and its ownership boundaries and wait for the actual remote Recovery probe to qualify. The full acceptance review follows actual remote build/test verification. Each Full run repeats Recovery readiness in its own VM; it does not accept another run's disk receipt. The ordinary diagnostic workflow and checked-in read-only hook keep their read-only behavior.
```sh
dotnet run --file tools/ci/MacOsNativeDiagnostic.cs -- --validate --full --source /path/to/pinned/dockur-clone --output artifacts/native-full-validation