ci: add darwin/arm64 unit and integration test jobs#63
Merged
Conversation
Adds two macOS jobs to complement the existing Linux pipeline so the applecontainer backend (runtime/applecontainer, darwin/arm64-only) gets CI coverage: - test-darwin (macos-15): builds the Swift bridge via `make bridge`, runs `go vet` and `go test -race ./...`. Exercises cgo compilation, go:embed of libACBridge.dylib, and the daemon-free unit tests. Daemon-dependent tests skip cleanly via runtimeOrSkip when Apple's `container` apiserver isn't running. Deterministic, blocks merges. - test-integration-darwin (macos-15, continue-on-error): installs the signed `apple/container` pkg from GitHub releases, brings up the apiserver + builder, and runs `TestAppleContainer_*` integration tests. Filtered with -run to skip the docker-backed tests that share the `integration` tag. Marked continue-on-error because Apple's runtime officially requires macOS 26 (vmnet networking doesn't work pre-26), and macos-15 is the newest hosted image GH Actions exposes today — this job exists to get empirical signal on what works, not to block merges. Drop continue-on-error once a green run on main establishes the contract. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds two macOS CI jobs on macos-26: ChangesmacOS CI Testing
Sequence Diagram — macOS integration test startup flow: sequenceDiagram
participant GitHubRunner
participant GHRelease as "GitHub Release"
participant XcodeSelector
participant Apiserver
participant Builder
participant GoTests
GitHubRunner->>GHRelease: gh release download installer-signed.pkg (auth via GITHUB_TOKEN)
GitHubRunner->>XcodeSelector: select Xcode compatible with Swift 6.2
GitHubRunner->>Apiserver: container system start --disable-kernel-install
Apiserver-->>GitHubRunner: apiserver ready
GitHubRunner->>Apiserver: container system kernel set --recommended
GitHubRunner->>Builder: start container builder
GitHubRunner->>GoTests: run TestAppleContainer_* (-tags=integration, -timeout=15m)
Estimated code review effort:
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
87-124: ⚡ Quick winAdd a job-level timeout for integration runs.
Only the
go testcommand is bounded; install/startup steps can still hang and occupy a macOS runner for hours. Addtimeout-minuteson the job.⏱️ Proposed change
test-integration-darwin: runs-on: macos-15 needs: [test-darwin] continue-on-error: true + timeout-minutes: 30 steps:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml around lines 87 - 124, The test-integration-darwin job can hang during setup; add a job-level timeout by adding a timeout-minutes field to the test-integration-darwin job definition (e.g., timeout-minutes: 60) so the entire job (including Install apple/container, Start container apiserver, Start builder, and Run apple-container integration tests steps) will be terminated after the configured minutes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 97-104: The workflow currently installs a downloaded .pkg as root
without verifying its installer identity; modify the step that downloads and
runs /tmp/container.pkg to verify its signer using pkgutil --check-signature and
compare the extracted "Developer ID Installer: <Name> (<Team ID>)" string to the
exact signer identity for apple/container (determine this by running pkgutil
--check-signature on a known release and copying the full signer line), and if
the signer does not match, abort before running sudo installer -pkg; use the
PKG_URL and /tmp/container.pkg variables already present to locate the file and
fail the job with a non-zero exit when the signature check does not match.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 87-124: The test-integration-darwin job can hang during setup; add
a job-level timeout by adding a timeout-minutes field to the
test-integration-darwin job definition (e.g., timeout-minutes: 60) so the entire
job (including Install apple/container, Start container apiserver, Start
builder, and Run apple-container integration tests steps) will be terminated
after the configured minutes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 18160ad6-57aa-4569-a3d5-087af77b81b3
📒 Files selected for processing (1)
.github/workflows/ci.yml
apple/container 0.12.3 declares swift-tools-version 6.2, which is only in Xcode 26.x. macos-15 runners ship multiple Xcode versions but default to an older one — pick the newest installed before running `make bridge`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The anonymous curl to api.github.com was rate-limited (HTTP 403) on shared CI egress IPs. Use `gh release download` with GH_TOKEN so the request goes against the authenticated 5k/hr limit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`container system start --disable-kernel-install` skips the interactive kernel prompt but leaves no kernel configured, so `container builder start` fails with "default kernel not configured for architecture arm64". Install Apple's recommended kernel non-interactively via `container system kernel set --from-recommended` between start and builder. Also confirms that `container system start` itself works on a macos-15 hosted runner — the apiserver came up cleanly in the previous run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Fix the kernel install flag: it's `--recommended`, not `--from-recommended`. The CLI surfaced "Unknown option" with the correct usage line; this aligns with `container system kernel set --help`. - Cache applecontainer-bridge/.build and SwiftPM's per-user checkout directory between runs, keyed on Package.resolved. The from-scratch bridge build was ~5-6 minutes (resolving apple/container + NIO/gRPC, then compiling); a warm cache should drop that to roughly the link step (~30s). Cache prefix is `v1` so we can force a full miss after a toolchain change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`container builder start` fails with VZErrorDomain Code=2
("Virtualization is not available on this hardware") on
GitHub-hosted macos-15 runners. The earlier steps (pkg install,
system start, kernel set) all succeed; the wall is reached only
when the runtime tries to actually boot a Linux guest VM.
Record the finding in the workflow comment so the constraint is
discoverable next time someone wonders why integration-darwin is
allowed to fail. The job stays in place (continue-on-error) so the
failure is visible and easy to retry once GH exposes VZ or we add
a self-hosted runner with virtualization entitlements.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
macos-26 (Tahoe) is now GA as a GitHub-hosted runner label. macos-15 doesn't expose Virtualization.framework for Linux guests, which blocks `container builder start` (Apple's runtime has no QEMU fallback like Colima/Lima). Bump both darwin jobs to macos-26 to see if VZ is exposed on the newer image. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/ci.yml (1)
119-130:⚠️ Potential issue | 🟠 Major | ⚡ Quick winVerify package signature before
sudo installerexecution.Line 129 installs a downloaded
.pkgas root without a signature gate. This is a supply-chain risk in CI.🔐 Minimal hardening patch
- name: Install apple/container env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | @@ gh release download --repo apple/container \ --pattern '*installer-signed.pkg' \ --output /tmp/container.pkg + # Fail closed if signer does not match expected Developer ID Installer identity. + EXPECTED_SIGNER="Developer ID Installer: Apple Inc. (TEAMID)" + pkgutil --check-signature /tmp/container.pkg | grep -Fq "$EXPECTED_SIGNER" \ + || { echo "::error::Unexpected package signer"; exit 1; } sudo installer -pkg /tmp/container.pkg -target / container --version🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml around lines 119 - 130, After downloading /tmp/container.pkg, add a signature verification step and fail the job if verification fails: run a package signature check (e.g., pkgutil --check-signature /tmp/container.pkg or spctl --assess --type install -v /tmp/container.pkg) and abort before running sudo installer -pkg /tmp/container.pkg -target /; ensure the CI step that currently runs gh release download and then sudo installer now checks the signature of /tmp/container.pkg and logs/fails explicitly if the signature check does not report a valid developer/macos installer signature.
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
109-113: ⚡ Quick winAdd an explicit timeout to prevent long-running macOS integration hangs.
This job exercises virtualization/runtime setup and can stall for a long time on hosted runners; adding
timeout-minutesimproves CI reliability/cost control.⏱️ Suggested change
test-integration-darwin: runs-on: macos-26 needs: [test-darwin] continue-on-error: true + timeout-minutes: 30 steps:Also applies to: 147-165
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml around lines 109 - 113, The test-integration-darwin GitHub Actions job (job id test-integration-darwin) can hang indefinitely on macOS runners; add a timeout-minutes property to the job definition to cap its runtime (e.g., timeout-minutes: 60) to prevent long-running stalls and control CI costs; also apply the same change to the other integration job referenced in the comment (the job block around lines 147-165) so both jobs have explicit timeouts.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In @.github/workflows/ci.yml:
- Around line 119-130: After downloading /tmp/container.pkg, add a signature
verification step and fail the job if verification fails: run a package
signature check (e.g., pkgutil --check-signature /tmp/container.pkg or spctl
--assess --type install -v /tmp/container.pkg) and abort before running sudo
installer -pkg /tmp/container.pkg -target /; ensure the CI step that currently
runs gh release download and then sudo installer now checks the signature of
/tmp/container.pkg and logs/fails explicitly if the signature check does not
report a valid developer/macos installer signature.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 109-113: The test-integration-darwin GitHub Actions job (job id
test-integration-darwin) can hang indefinitely on macOS runners; add a
timeout-minutes property to the job definition to cap its runtime (e.g.,
timeout-minutes: 60) to prevent long-running stalls and control CI costs; also
apply the same change to the other integration job referenced in the comment
(the job block around lines 147-165) so both jobs have explicit timeouts.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 894a8a10-52de-4926-8b7d-f2b4c63e3385
📒 Files selected for processing (1)
.github/workflows/ci.yml
Bumping the runner to macos-26 (the newest hosted image GH offers) produced the same VZErrorDomain Code=2 failure as macos-15. This confirms the limitation is at the runner-platform layer, not a per-image setting — GH hosted macOS runners simply do not expose Virtualization.framework for Linux guests. Update the workflow comment so the next engineer doesn't re-derive this. Apple's `container` runtime has no QEMU fallback, so there's no workflow-level workaround; we need a self-hosted runner or for GH to expose VZ. continue-on-error stays. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
118-122: ⚡ Quick winAdd an explicit timeout to the non-blocking integration job.
This job can still hang on runtime startup paths; without
timeout-minutes, it can run for the default ~6h and delay CI feedback.💡 Suggested change
test-integration-darwin: runs-on: macos-26 needs: [test-darwin] continue-on-error: true + timeout-minutes: 30 steps:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml around lines 118 - 122, The non-blocking GitHub Actions job "test-integration-darwin" lacks an explicit timeout and can hang for hours; add a timeout-minutes field to the job definition (e.g., timeout-minutes: 30) under the "test-integration-darwin" job to bound its execution and prevent long CI stalls.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 118-122: The non-blocking GitHub Actions job
"test-integration-darwin" lacks an explicit timeout and can hang for hours; add
a timeout-minutes field to the job definition (e.g., timeout-minutes: 30) under
the "test-integration-darwin" job to bound its execution and prevent long CI
stalls.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 99348e37-e936-4676-bcf2-70d3473ec28c
📒 Files selected for processing (1)
.github/workflows/ci.yml
The previous workflow keyed the SwiftPM cache on
hashFiles('applecontainer-bridge/Package.resolved'), but that file
was in .gitignore — it didn't exist on the freshly-checked-out
runner, so hashFiles returned an empty string and every key
collapsed to the prefix `swiftpm-v1-macOS-ARM64-`. With prefix-only
keys, the cache was technically restored but reflected whichever
toolchain happened to populate it last, so SwiftPM rebuilt from
scratch whenever the OS image moved.
Track Package.resolved in the repo — standard SwiftPM convention
for top-level applications (the bridge ships a dylib, it's not
consumed as a SwiftPM library) — so the cache key resolves to a
real hash and warm builds actually hit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Job-level `continue-on-error: true` only stops the workflow run
from failing — the individual job still shows red on the PR check
list, which is the noise that was bugging me. Move the lenience
to the step level: mark `Start builder` continue-on-error and gate
the test step on its outcome.
Net effect:
- Hosted runner (VZ unavailable): builder step fails inline,
tests are skipped, job ends green.
- Self-hosted runner (or future hosted with VZ): builder
succeeds, tests run, job is green or red on real signal.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
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
1 participant
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.
Summary
Extends the CI pipeline with two macOS jobs so the apple-container backend gets coverage equivalent to the Linux side:
test-darwin(macos-15) — builds the Swift bridge and runs the Go test suite on darwin/arm64. Exercises cgo,go:embedoflibACBridge.dylib, and daemon-free unit tests. Daemon-dependent tests skip cleanly. Deterministic, blocks merges.test-integration-darwin(macos-15,continue-on-error: true) — installs the signedapple/container.pkgfrom GitHub releases, brings up the apiserver + builder, runsTestAppleContainer_*integration tests. Markedcontinue-on-errorbecause Apple's runtime officially requires macOS 26 (vmnet networking doesn't work pre-26) andmacos-15is the newest hosted image available. The job exists to get empirical signal on what works on the current runner — dropcontinue-on-erroronce a green run onmainconfirms the contract.Test plan
test-darwingoes greentest-integration-darwinproduces useful output (either green or a clear failure mode pointing at macOS 15 vs 26)🤖 Generated with Claude Code
Summary by CodeRabbit