fireactions

Recipe card from the charly-fireactions plugin (Kinds — schema authoring).

Fireactions — GitHub Actions runners on Firecracker microVMs

A runner is a microVM: fireactions schedules a pool of them and hands each job a fresh one. Everything that makes a microVM work applies (see the firecracker skill), plus the pool’s own constraint.

The constraint that decides whether a pool can run at all

Fireactions configures containerd with a snapshotter chosen in the layer’s containerd: connection, and the accepted set is exactly two: devmapper and blockfile — the fork’s SnapshotterBacksRootDrive accepts nothing else, because native and overlayfs cannot back a microVM root drive. devmapper needs a spare block device, so on a host with none — a plain workstation — the pool cannot start, and the failure names containerd rather than the missing device. The snapshotter is therefore the field to look at FIRST when a pool will not come up.

The device-less path is blockfile, and it takes two layers to work: opencharly/layer-containerd serves it — the plugin CLONES a pre-existing scratch image, so the layer creates and formats that file before the daemon starts, and without it the plugin reports error rather than ok — and opencharly/layer-fireactions declares snapshotter: blockfile in its containerd: connection. Its bed then asserts the daemon-reported served set, which is the check that cannot pass by accident: a grep of the rendered config would pass while the substrate could not start.

The fork, and why it is pinned

The opencharly fork carries the changes this integration needs; consumers pin the tag, not a branch. v2.0.8-oc1 is the pinned release. Advance it only through the producer-first order: fork PR → merge → tag → consumer pin bump.

The pieces

• the host layer installs the VMM binary, the jailer and the fireactions kernel on the venue — the things a pool needs before any runner can exist;
• the runner is the pool member: a microVM booted from the root-drive + kernel pair;
• the beds are check-fireactions-host (the host layer lands and the pool’s prerequisites are present) and check-fireactions-runner (a runner comes up on that host).

Two traps worth knowing before you debug

• A guest that needs plugins does not have them. A deploy provides its target the host’s charly binary and nothing else — no candy corpus — so any step that dispatches a plugin verb in the guest fails with an unknown word, and the fix is charly-side (opencharly/charly#916), not a workaround in the bed.
• A candy referenced by a remote @github ref does not apply its service: block the way a local ref does (opencharly/charly#918), which is why a layer that starts a unit can look installed and still have the unit inactive.