didericis/bot-bottle
1
0
Fork 0
Code Issues 36 Pull Requests 3 Actions Packages Releases Wiki Activity

CI: no macOS (Apple Container) runner — macos_container backend is unexercised #426

New Issue
Open
opened 2026-07-20 13:36:47 -04:00 by didericis · 0 comments
didericis commented 2026-07-20 13:36:47 -04:00
Owner
Copy Link
Copy Source

Background

CI has no runner for the macos_container (Apple Container) backend. .gitea/workflows/test.yml runs on ubuntu-latest and a self-hosted [self-hosted, kvm] Linux box — there is no macos, darwin, or apple runner anywhere. Docker and Firecracker are both exercised; macos_container is not.

This is not theoretical. 5ad3449 moved bot_bottle from flat files under /app into a pip-installed package but left init scripts spawning the supervisor as python3 /app/gateway_init.py, which no longer exists. Both the firecracker and macos-container backends had the identical bug:

  • firecracker — caught, and fixed in 127ba49, because the KVM runner added in c193b04 (PR #349) actually runs that backend's integration suite.
  • macos_container — survived on main and only surfaced when a human ran bot-bottle start by hand.

The failure mode is also expensive to debug: the supervisor never starts, so mitmdump never generates its CA, and the launch dies downstream with GatewayError: gateway CA not available, which points at TLS rather than at the supervisor.

The unit tests did not help. test_macos_infra asserted the substring "gateway_init.py", which the broken path satisfies, so it stayed green. Its firecracker twin was tightened to the module form as part of 127ba49; the macOS one was not.

Proposal

Provision a self-hosted macOS runner (label e.g. macos, on Apple Silicon with Apple Container installed) and add an integration-macos job alongside the existing integration-docker and integration-firecracker jobs.

Considerations

  • Must be a physical/VM macOS host — Apple Container cannot run in a Linux container, so this cannot reuse the KVM runner.
  • Gate the job on preconditions the way integration-firecracker does (command -v container, a working container system status) so a misprovisioned runner fails loudly rather than silently skipping.
  • Decide whether the job is required on PRs or advisory-only, given it will be a single non-redundant machine.
  • Teardown matters: the infra container is a singleton (bot-bottle-mac-infra), so parallel jobs on one runner will collide. See #425 for the equivalent problem already hitting the KVM runner.

Acceptance criteria

  • A macOS runner is registered and picks up jobs by label.
  • An integration-macos job runs the integration suite against BOT_BOTTLE_BACKEND=macos-container.
  • The job fails (not skips) when the backend is unavailable on the runner.
  • Reverting the macos_container/infra.py fix makes the job fail.

Related

  • #414 — backend-agnostic integration tests and per-backend skip visibility (adjacent; this issue is about the missing runner itself, not test structure)
  • #425 — shared infra singleton breaks parallel jobs on the KVM runner; same hazard applies here
  • #387 — cross-distro Firecracker end-to-end tests
## Background CI has no runner for the `macos_container` (Apple Container) backend. `.gitea/workflows/test.yml` runs on `ubuntu-latest` and a self-hosted `[self-hosted, kvm]` Linux box — there is no `macos`, `darwin`, or `apple` runner anywhere. Docker and Firecracker are both exercised; `macos_container` is not. This is not theoretical. `5ad3449` moved `bot_bottle` from flat files under `/app` into a pip-installed package but left init scripts spawning the supervisor as `python3 /app/gateway_init.py`, which no longer exists. Both the firecracker and macos-container backends had the identical bug: - **firecracker** — caught, and fixed in `127ba49`, because the KVM runner added in `c193b04` (PR #349) actually runs that backend's integration suite. - **macos_container** — survived on `main` and only surfaced when a human ran `bot-bottle start` by hand. The failure mode is also expensive to debug: the supervisor never starts, so mitmdump never generates its CA, and the launch dies downstream with `GatewayError: gateway CA not available`, which points at TLS rather than at the supervisor. The unit tests did not help. `test_macos_infra` asserted the substring `"gateway_init.py"`, which the *broken* path satisfies, so it stayed green. Its firecracker twin was tightened to the module form as part of `127ba49`; the macOS one was not. ## Proposal Provision a self-hosted macOS runner (label e.g. `macos`, on Apple Silicon with Apple Container installed) and add an `integration-macos` job alongside the existing `integration-docker` and `integration-firecracker` jobs. ## Considerations - Must be a physical/VM macOS host — Apple Container cannot run in a Linux container, so this cannot reuse the KVM runner. - Gate the job on preconditions the way `integration-firecracker` does (`command -v container`, a working `container system status`) so a misprovisioned runner fails loudly rather than silently skipping. - Decide whether the job is required on PRs or advisory-only, given it will be a single non-redundant machine. - Teardown matters: the infra container is a singleton (`bot-bottle-mac-infra`), so parallel jobs on one runner will collide. See #425 for the equivalent problem already hitting the KVM runner. ## Acceptance criteria - [ ] A macOS runner is registered and picks up jobs by label. - [ ] An `integration-macos` job runs the integration suite against `BOT_BOTTLE_BACKEND=macos-container`. - [ ] The job fails (not skips) when the backend is unavailable on the runner. - [ ] Reverting the `macos_container/infra.py` fix makes the job fail. ## Related - #414 — backend-agnostic integration tests and per-backend skip visibility (adjacent; this issue is about the missing runner itself, not test structure) - #425 — shared infra singleton breaks parallel jobs on the KVM runner; same hazard applies here - #387 — cross-distro Firecracker end-to-end tests
gitea-actions bot added the Status/Needs Triage label 2026-07-20 13:36:53 -04:00
didericis added the Kind/EnhancementKind/Testing labels 2026-07-20 13:36:57 -04:00
didericis added
Priority
Low
4
 and removed Status/Needs Triage labels 2026-07-20 13:41:55 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status/Needs Triage
Awaiting initial classification
No Label Kind/Enhancement Kind/Testing
Priority
Low
4
Milestone
No items
No Milestone
Assignees
Clear assignees
didericis-claude (didericis (claude)) didericis-codex (didericis (codex)) didericis-gemma (gemma) didericis
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: didericis/bot-bottle#426
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?