Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -21,10 +21,10 @@ permissions:

# ---------------------------------------------------------------------------------
# Two jobs. It was five, because `task ci:full` could not run on one hosted runner: the
# guest lanes needed the pinned QEMU, only executable inside the published runtime image
# (ADR-0025), and a container job gets no Docker daemon for the TestContainers lanes.
# Nothing in the merge gate needs QEMU now. The `gate` job below stays regardless — its
# reason never depended on the split.
# guest lanes needed a QEMU that was dynamically linked and so only executable inside the
# image that built it, and a container job gets no Docker daemon for the TestContainers
# lanes. QEMU is static now and nothing in the merge gate needs it anyway. The `gate` job
# below stays regardless — its reason never depended on the split.
# ---------------------------------------------------------------------------------

jobs:
Expand Down
8 changes: 4 additions & 4 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -147,14 +147,14 @@ task db:dev:up|down # pinned Postgres 18
task db:plan -- <name> # DDL for the current schema.sql change → migrations/
task db:apply PLAN=<f> # apply a *saved* plan, never a recomputed one
task db:verify # schema.sql → empty DB; assert the plan is empty
task qemu:build / qemu:verify / qemu:version / qemu:tools
task guest:kernel:fetch / guest:build / guest:verify
task machine # fetch the pinned spin-machine release into _output/
task guest:build / guest:verify
task demo:stage1 # Stage 1 end to end: a Linux guest boots off our qcow2
task backend:conformance # §6.1 object-store conformance (blocking per backend)
```

QEMU is built by `.github/workflows/qemu.yml` (not the per-push gate), which calls the
same Taskfile targets a developer runs and publishes `ghcr.io/<owner>/<repo>/qemu:<ver>`.
QEMU, the guest kernel and the firmware are not built here: `task machine` fetches one
`spin-stack/spin-machine` release, pinned by version and SHA-256 in `Taskfile.yml`.
Test object store: RustFS, pinned by digest, via TestContainers (`internal/testinfra`);
the S3 SDK is confined to `internal/simio/real/s3*.go` behind `objectstore.Store`, and
nothing else in the tree imports it.
Expand Down
7 changes: 0 additions & 7 deletions docs/plan/DECISIONS/ADR-0021-integration-with-spin.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,13 +54,6 @@ Everything else stays internal and stays free to change. A narrow surface is wha
format work (a human-review zone) from becoming a compatibility obligation to another
repository.

### 5. The guest kernel is consumed as an artefact, not as code

storage's test lane needs a Linux guest that can issue FLUSH. spinbox already builds one.
storage consumes **the built kernel image**, pinned the way `RUSTFS_IMAGE` is pinned — a
build-time dependency on a binary, reversible by changing a path, with no Go import in
either direction. storage never builds a kernel.

## What this does not decide

- **When.** Integration starts when storage serves one volume end to end, not before.
Expand Down
58 changes: 0 additions & 58 deletions docs/plan/DECISIONS/ADR-0022-guest-kernel-pinned-and-mirrored.md

This file was deleted.

This file was deleted.

2 changes: 1 addition & 1 deletion hack/demo-lib.sh
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ SIZE=${SIZE:-268435456}
# reaching a qcow2 through virtio, and that is true at either speed; refusing to run
# without KVM would make the one command a human runs unrunnable on a developer outside
# the `kvm` group and on every hosted CI runner. A host serving tenants is the opposite
# case, which is why the binary it runs has no TCG in it at all (Dockerfile.qemu).
# case, which is why the production binary in a release has no TCG in it at all.
#
# Chosen here rather than left to QEMU's `kvm:tcg` fallback list, which would pick the
# same thing and say nothing. The silence is the problem: a machine that should have KVM
Expand Down
8 changes: 2 additions & 6 deletions hack/spin-machine
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,8 @@
#
# Put a spin-machine release under _output/, from wherever one is available.
#
# This repository builds no QEMU and no kernel. It used to do both — a Dockerfile.qemu
# modelled on another project's, a device list that was byte-for-byte that project's, and a
# Dockerfile.guest-kernel that built nothing at all and existed only to move somebody
# else's kernel through a registry and back out. All three are gone: QEMU, the guest kernel
# and the firmware are one versioned artefact, and this is the only path by which one
# arrives.
# This repository builds no QEMU and no kernel. They are one versioned artefact, pinned by
# version and by SHA-256 in Taskfile.yml, and this is the only path by which one arrives.
#
# Two sources, in order:
#
Expand Down
8 changes: 3 additions & 5 deletions taskfiles/machine.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,11 +2,9 @@ version: "3"

# The machine this repository runs guests on: QEMU, the guest kernel, the firmware.
#
# None of it is built here. It used to be — a Dockerfile.qemu modelled on another
# project's, a device list that was byte-for-byte that project's, and a
# Dockerfile.guest-kernel that built nothing and existed only to move somebody else's
# kernel through a registry and back out (ADR-0022). All of that has one home now, and
# `task machine` is the only path by which a machine arrives.
# None of it is built here, and none of it is mirrored here. QEMU, the guest kernel and
# the firmware are one versioned artefact from spin-machine, pinned by version and by
# SHA-256 below; `task machine` is the only path by which a machine arrives.

tasks:

Expand Down
Loading