Skip to content

ci(macos): self-provision libkrun via brew - #508

Merged
norrietaylor merged 1 commit into
mainfrom
fix/ci-macos-provision-libkrun
Jun 22, 2026
Merged

ci(macos): self-provision libkrun via brew#508
norrietaylor merged 1 commit into
mainfrom
fix/ci-macos-provision-libkrun

Conversation

@norrietaylor

@norrietaylor norrietaylor commented Jun 21, 2026

Copy link
Copy Markdown
Member

Make the macOS CI install libkrun itself instead of depending on hand-provisioned self-hosted-runner state.

Why

The three macOS jobs (build-macos, boot/autospawn e2e, minvmd FFI smoke) only verified /opt/homebrew/lib/libkrun.dylib existed and errored otherwise — libkrun was expected to be pre-provisioned on the self-hosted Apple Silicon runner. That runner state silently went missing, so build-macos fails on every Rust code PR (libkrun.dylib not found). build-macos is on the critical path of the minimald networking epic — it blocks #507 and all of #496#502.

History note: there was never a libkrun install/fetch step in ci-macos.yml (scripts/fetch-libkrun.sh exists but fetches the Linux .so package and is only wired into ci-linux-kvm.yml). So this is a runner-provisioning gap, not a regression — and the durable fix is to stop depending on runner state.

Change

Add an idempotent provision step before each Verify guard:

- name: Provision libkrun (slp/krun tap)
  run: brew install slp/krun/libkrun
  • Same slp/krun tap the runner setup already used → supply-chain surface unchanged.
  • brew install is a no-op when already present.
  • Drops the now-inaccurate "CI does not install it" comment.

Self-validating

This PR's own build-macos (+ boot/autospawn/FFI) jobs run the new step first, so a green run proves the fix end-to-end.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Updated macOS CI workflow to automatically self-provision required dependencies across multiple test jobs on ARM64 self-hosted runners, improving build automation.

…er state

The three macOS jobs (build-macos, boot/autospawn e2e, minvmd FFI smoke) only
verified that /opt/homebrew/lib/libkrun.dylib was present and errored if not —
libkrun was expected to be hand-provisioned on the self-hosted Apple Silicon
runner. That runner state silently went missing, failing every Rust code PR on
build-macos (a required check on the critical path of the minimald networking
epic).

Add an idempotent `brew install slp/krun/libkrun` step before each Verify guard
so CI provisions libkrun itself. It is the same slp/krun tap the runner setup
used, so the supply-chain surface is unchanged; `brew install` is a no-op when
already present. Drops the now-inaccurate "CI does not install it" comment.

Self-validating: this PR's own build-macos run executes the new step, so a green
run proves the fix.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ss8WXtUUr9PBHuJcJMseBj
@coderabbitai

coderabbitai Bot commented Jun 21, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f749e848-4069-4699-b5fe-287f125a0bb5

📥 Commits

Reviewing files that changed from the base of the PR and between cf60857 and e98ba91.

📒 Files selected for processing (1)
  • .github/workflows/ci-macos.yml

📝 Walkthrough

Walkthrough

The macOS CI workflow gains an explicit brew install slp/krun/libkrun step in the boot-e2e, autospawn-e2e, and build-macos jobs. This replaces the prior model where libkrun.dylib had to be pre-provisioned on the self-hosted runner; the build-macos job also drops its accompanying disclaimer comments.

Changes

libkrun auto-provisioning across macOS CI jobs

Layer / File(s) Summary
Add brew install step to boot-e2e, autospawn-e2e, and build-macos jobs
.github/workflows/ci-macos.yml
Each of the three jobs receives a brew install slp/krun/libkrun step before its existing libkrun verification check. In build-macos, the prior comments about manual pre-provisioning are removed alongside the new install step.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

  • gominimal/minimal#283: Also modifies .github/workflows/ci-macos.yml to handle libkrun.dylib provisioning on the self-hosted macOS ARM64 runner, directly related to the same brew install slp/krun/libkrun behavior being changed here.

Poem

🐰 Hop hop, no more manual prep,
The brew command handles each step!
libkrun installs with a tap,
No runner pre-work on the map.
CI flows smooth as a bunny's leap! 🍺

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'ci(macos): self-provision libkrun via brew' directly and concisely summarizes the main change: adding self-provisioning of libkrun via Homebrew in the macOS CI workflow.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Comment @coderabbitai help to get the list of available commands and usage tips.

@norrietaylor
norrietaylor enabled auto-merge (squash) June 21, 2026 04:52
@norrietaylor
norrietaylor disabled auto-merge June 21, 2026 22:17
@norrietaylor
norrietaylor enabled auto-merge (squash) June 21, 2026 22:17

@bryan-minimal bryan-minimal left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@norrietaylor
norrietaylor merged commit 20ea9be into main Jun 22, 2026
29 checks passed
@norrietaylor
norrietaylor deleted the fix/ci-macos-provision-libkrun branch June 22, 2026 02:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants