Nucleic: Gitea Runner macOS VM Support
This commit is contained in:
@@ -105,6 +105,25 @@ jobs:
|
||||
The daemon picks the job up within one poll interval, boots a VM, and tears it down when the job
|
||||
finishes.
|
||||
|
||||
## CI
|
||||
|
||||
This repo builds itself. [`.gitea/workflows/build.yml`](.gitea/workflows/build.yml) runs on
|
||||
`macos-arm64` — the very runners this project provides — and does a full `swift test`, `make all`,
|
||||
and a check that the resulting `.app` carries the virtualization entitlement and its runtime
|
||||
resources. A green run is also an end-to-end test of the runner: it means a guest image really can
|
||||
check out a repo, run the Swift toolchain, and produce a signed bundle.
|
||||
|
||||
For it to run at all you need:
|
||||
|
||||
- the repo pushed to a Gitea **1.25 or newer** instance with Actions enabled
|
||||
(`[actions] ENABLED = true`),
|
||||
- `gitea-macos-runner daemon` running on an Apple silicon host and registered with that instance,
|
||||
- a base image built and provisioned (`image build`) — `image list` should show `PROVISIONED: yes`.
|
||||
|
||||
The workflow deliberately runs no `doctor`, `vm`, `daemon`, or `image` steps. Those start a VM or
|
||||
probe the host's ability to start one, and the job is already inside a guest; Virtualization
|
||||
does not nest, so they would fail for reasons that say nothing about the code.
|
||||
|
||||
## Documentation
|
||||
|
||||
- [docs/setup.md](docs/setup.md) — full Gitea-side and host-side walkthrough, config reference,
|
||||
|
||||
Reference in New Issue
Block a user