Runbook

Rules and design: docs/SPEC.md. Below, ciburst stands for the release binary or cargo run -p ciburst --.

Facts

Developer setup

1. Config: copy config.example.json to .local/config.json; set name, gitlab.projectIds, vm and the host's lanes (spec section 5.4).Checkciburst plan --config .local/config.json --skip-gitlab reports no config error; it stops at SCW_SECRET_KEY missing in .local/scaleway.env until step 2.
2. Scaleway: in the console, IAM, an application with a policy on the organization holding IAMManager, ProjectManager, InstancesFullAccess, ServerlessJobsFullAccess, FunctionsFullAccess and ObjectStorageFullAccess (ContainerRegistryFullAccess only with provider.registry), and an API key. Write SCW_ACCESS_KEY, SCW_SECRET_KEY, SCW_DEFAULT_ORGANIZATION_ID (optional SCW_DEFAULT_PROJECT_ID) to .local/scaleway.env, then chmod 600 .local/scaleway.env.Checkthe plan of step 1 prints the provider and host steps without an authentication error.
3. GitLab: a personal access token of a project Owner with the scopes api and create_runner and an expiry. Write GITLAB_TOKEN=<token> to .local/gitlab.env, then chmod 600 .local/gitlab.env.Checkciburst plan --config .local/config.json prints runner and hook steps.
4. Agent: scripts/agent-binary.sh writes the Linux musl agent to .local/ciburst-vm-agent.Checkthe plan lists the agent object as create, or noop when this build is already uploaded; the runner object (runner-binary) as create, or noop once uploaded.
5. ciburst apply --config .local/config.json.Checkexits 0; .local/outputs.env holds CIBURST_DISPATCH_URL.
6. ciburst plan --config .local/config.json.Checkonly noop lines.
7. ciburst check --config .local/config.json (--ref <branch> lints a branch before it is merged; --suggest proposes lanes, section Lanes).Checkevery job matches its lanes and the VM runner for every project.
8. ciburst status --config .local/config.json.Checkthe dispatcher URL, vm runner <tag>: <n> live of <maxRuns> and a line per lane.

.local/ is gitignored and never committed:

Adopter setup

The adopter follows README, Adopt. The operator's view:

1. Component: an include: entry component: gitlab.com/ciburst/ciburst/ciburst@1 (the newest 1.x release) in the project's .gitlab-ci.yml; deployments made before 1.0.0 include @main.Checka default-branch pipeline shows ciburst-setup, ciburst-check, ciburst-destroy and ciburst-invite as manual jobs in .pre.
2. Variables: CIBURST_SCW_ACCESS_KEY, CIBURST_SCW_SECRET_KEY, CIBURST_SCW_ORGANIZATION_ID, CIBURST_GITLAB_TOKEN; optional CIBURST_SCW_PROJECT_ID (an existing Scaleway project instead of a new one). Each protected, masked and hidden, environment scope ciburst.CheckSettings, CI/CD, Variables lists them with environment ciburst.
3. Run ciburst-setup.Checkthe log prints the plan and a replayed line per waiting job; those jobs run on the runner <name>-vm; a second run prints only noop. Note the job's duration: it counts against the hosted-runner minutes.
4. Run ciburst-check.Checkevery job matches its lanes and the VM runner.
5. Undo: the project variable CIBURST_DESTROY=<name> (protected, environment scope ciburst), then run ciburst-destroy.Checkdestroyed <name>; no output variable, webhook or runner remains; delete CIBURST_DESTROY afterwards. A warn line names what is left; a second run removes it. Remove the include only after this: a revert alone leaves the webhook, and every later job still starts a VM.

Project variables after a setup, environment ciburst, protected, raw: the keys of outputs.env above. Tokens, secrets and secret keys are masked and hidden where GitLab allows; ids, URLs and the agent hash stay readable in job logs.

Where to look when a job waits:

1. The job's tags. A job without the tag of the runner its name routes it to (its lane's, else the VM runner's) waits for another runner; ciburst-check names it.
2. The webhook's recent events (Settings, Webhooks, Edit, Recent events): the job's pending delivery and its answer (section Dispatcher answers). No delivery: the webhook is missing or disabled (section Webhook health); ciburst-setup re-verifies the host's and replays waiting jobs, ciburst-join recreates a member's missing webhook.
3. started or grouped for a VM job: a VM boots in about a minute; its tags go from starting to idle or busy.
4. queued: the job waits for a busy slot; a VM starts for it when the wait would pass maxQueueS (section Queue first).
5. claimed: a polling slot of the VM runner takes the job within seconds; if none does, read the VMs' tags (section VM runtime and the sweep).
6. started for a lane: the run takes the job within 5 to 28 s (93 s at 6 vCPU) plus its bootstrap. A job still pending after a minute: ciburst status shows the run; a Failed run's log names the cause with ciburst-lane: (section Failure modes).
7. at_capacity: maxRuns lane runs of the lane run; the job starts when a run takes it or ends.
8. ignored with reason no_runner: the member registered no VM runner; run ciburst-join there.
9. 500: the start failed; section Failure modes.
10. Jobs created before the first setup: ciburst-setup replays jobs pending for more than 60 s.

Dispatcher answers

Every answer with a body carries ms, the dispatcher's elapsed milliseconds; GitLab.com counts an answer after 10 s as a failed delivery and disables the webhook after four failures in a row (section Webhook health). Every 200 answer of a job event except ignored also names the runner and its kind: the VM runner's tag with vm, or the lane's tag with lane. Example: {"result":"started","runner":"node24","kind":"lane","runId":"<run id>","ms":1840}. A grouped job depends on its leader's delivery: started (the VM boots), queued or at_capacity (the group waits for a slot) or 500 (the group waits for the next VM). Lane jobs never answer grouped, duplicate or queued: lanes use neither the burst ledger nor the queue. The fleet endpoints answer as in section Fleet members.

Fleet members

Rules: spec section 8.

• State: ciburst/fleet/config.json (the host's config with a MAC; ciburst-setup writes it, the dispatcher reads it within 30 s) and ciburst/fleet/members/<project id>.json (webhook secret, VM runner token, lanes, ignoreJobs; secrets sealed with AES-256-GCM under CIBURST_FLEET_KEY). These keys never expire; never edit them by hand: a forged config or record makes the reads fail (warn fleet_failed).
• Invite: ciburst-invite with CIBURST_INVITE writes the code to its artifact join-code.txt (Maintainers and Owners, 7 days), never into the log (D73); ciburst invite <project> prints it. The code carries the dispatcher URL, the project id and a 7-day expiry, signed with the hook token. Rotating the hook token (ciburst rotate hook) invalidates open codes; joined members keep the webhook secret stored at their join.
• VMs serve every member: each VM runs one gitlab-runner run with an entry per member VM runner, from the runners of the report answer.
• Status: ciburst status prints member <id> joined <time>, each member's lanes and deliveries; ciburst check lints every member against its own lanes; ciburst-destroy refuses with fleet <name> has members <ids>: run ciburst-leave there first.

Join a project:

1. The project's own ciburst.json, when it gets lanes or has jobs on other runners: only lanes and ignoreJobs.Checkno other top-level key; a fleet setting fails the join with <key>: a fleet setting; it belongs in the host's ciburst.json.
2. In the host, CIBURST_INVITE=<project id or path>, then ciburst-invite; the code is in its artifact join-code.txt (job page, Job artifacts, Browse).Checkjoin code for project <id>, valid until <time>, in the artifact join-code.txt; the log holds no code.
3. In the member, CIBURST_JOIN (the code) and CIBURST_GITLAB_TOKEN, both protected, masked and hidden, scope ciburst; then ciburst-join.Checkthe log shows info runner tag="<vm tag>", info runner tag="<lane tag>" per lane, info hook, then lane <tag> (<image>) per lane and joined fleet <name>; the member's Runners page lists <name>-<vm tag> and <name>-<lane tag>; the console lists the job definitions <name>-<project id>-<lane tag>.
4. A member pipeline.Checkthe deliveries answer with runner <vm tag> and kind vm for VM jobs, <lane tag> and lane for lane jobs; ciburst status in the host lists lane <tag> of project <id> (<image>).

Change a member's lanes or ignoreJobs: edit its ciburst.json, then ciburst-join again (a new code from the host when the old one expired). /join updates changed definitions and deletes those of removed lanes; ciburst-join replaces the member's runners.

/join answers, shown in the failing ciburst-join log as POST /join: <status> <body>:

Leave: ciburst-leave in the member posts /leave (an expired code still leaves), which deletes the member's job definitions and record, then deletes its webhook and runners and prints left fleet <name>. /leave fails with the same 500 error or 504 timeout and step.

Migrate a deployment to the VM runner and project lanes

A config with pools, defaultPool, stages, vmFirst, spillRunner or providers is refused; there is no automatic migration.

1. Host ciburst.json: replace pools by vm and lanes. vm takes the pools entry with runtime instances: its tag, image, slots, instanceTypes, maxRuns, maxQueueS and warmStart, without runtime, jobs and stages. lanes takes each entry with runtime jobs: its tag, image, jobs, sizes and maxRuns, without runtime, stages and vmFirst. Remove defaultPool, spillRunner and providers. A job that a lane took by stage needs its name in that lane's jobs.Checkciburst plan (or the setup's first lines) reports no config error.
2. Component input: pool is now vm_tag, in the host and in every member; leave it out for the default vm.Checkthe CI file validates.
3. Run ciburst-setup in the host.Checkthe plan creates definition:<project id>-<tag> and deletes the old definition:<tag> per host lane, sets the runner <name>-<vm tag> to set tags <vm tag>, deletes <name>-<vm tag>-spill when it exists, and disables host lane runners in the further projects of gitlab.projectIds; ciburst-check passes.
4. Each member that used the host's lanes: its own ciburst.json with its lanes (same tags as before, so its jobs keep their tags:) and its ignoreJobs, then ciburst-join.Checklane <tag> (<image>) per lane and joined fleet <name>; a member pipeline runs its lane jobs on <name>-<lane tag> of its own project.
5. Remove from the host's ignoreJobs the names of members' jobs, and from its lanes any lane only members used; ciburst-setup.Checkciburst status lists each lane under its own project.

Webhook health

GitLab disables a webhook after four failed deliveries in a row, and GitLab.com counts an answer after 10 s as failed. A disabled webhook delivers nothing, so pending jobs wait without a trace.

1. Detect: ciburst check (the ciburst-check job) prints project <id>: webhook <alert_status> until <time or never>: run ciburst-setup to enable it again and exits 1; ciburst status prints hook <id>: <alert_status>.
2. Repair: ciburst-setup (or ciburst apply). The plan shows update gitlab hook in project <id> (re-enable: <alert_status> until <time or never>); apply sends GitLab's test delivery, which the dispatcher answers 200, logs hook_reenabled and replays the waiting jobs. A member's hook: in the member, Settings, Webhooks, the hook, Test, which sends a delivery the dispatcher answers 200.Checkciburst status prints hook <id>: executable; the waiting jobs start.
3. Cause: the deliveries in ciburst status show the failed answers and their ms.

Logs

Every line reads <level> <message> key="value" ... and never holds a secret.

Rotation and updates

Check after each: ciburst plan prints only noop; a test pipeline passes.

1. Yearly runtime bump: the new Rust version in rust-toolchain.toml and the host runtime (RUNTIME in crates/scaleway/src/host.rs), then in every file scripts/check-pins.sh lists (it runs in the lint job); tag a release; ciburst apply.Checklint passes; the function is ready; a test pipeline passes.
2. Runner bump: the new version and its SHA-256 (from the release's release.sha256) in RUNNER_URL and RUNNER_SHA256 of crates/core/src/cloud_init.rs, then in every file scripts/check-pins.sh lists; ciburst apply.Checkthe plan shows create for the runner object (runner-binary) and update for every host definition:<project id>-<tag>; members update theirs with ciburst-join; VMs created and lane runs started afterwards run the new version.
3. Agent: after a change in crates/vm-agent, scripts/agent-binary.sh, then ciburst apply; in pipeline mode a new cli image carries the agent and ciburst-setup uploads it. VMs created afterwards download the new object.CheckCIBURST_AGENT_SHA256 in the outputs changed; the plan lists delete vm agent ciburst/agent/<sha256> for each agent older than the two before it.

Release

1. Version: version in [workspace.package] of Cargo.toml and the version of each internal path dependency in crates/*/Cargo.toml become X.Y.Z; cargo build updates Cargo.lock; commit and push to main.Checkthe main pipeline passes; cargo run -p ciburst -- --version prints ciburst X.Y.Z.
2. Tag: git tag X.Y.Z on that commit, git push origin X.Y.Z; no v (D71).Checkthe tag pipeline runs lint, deny, test, lane-bootstrap, image:cli, release:binary and release; the release links both binaries and their checksums; Build, CI/CD Catalog lists X.Y.Z; registry.gitlab.com/ciburst/ciburst/cli:X.Y.Z exists.
3. Deployments: a project that includes @1 runs the new jobs from its next pipeline on; its ciburst-setup uploads the new agent and redeploys the function when the code changed.Checkin a project on @1, the ciburst-setup log pulls cli:X.Y.Z; ciburst-check passes.

Site

Rules: spec section 11.5, D75.

• Build: cargo run -p ciburst-site -- public writes the site into public/ (gitignored); open public/index.html. cargo test -p ciburst-site checks the pages, every internal link and anchor, and the weight of the first view.
• Deploy: the job pages on main runs when the README, AGENTS.md, docs/, the crate or the CI file change; GitLab Pages serves its artifact.
• The site maps README sections by their titles: a renamed section fails the build with README.md: no section "## <title>".

Domain, once:

1. Settings, General, Visibility: Pages visible to everyone.Checkafter the first pages job, the project's Pages URL (Deploy, Pages) opens without a session.
2. Deploy, Pages, New domain: ciburst.zwa.la with an automatic certificate; GitLab shows the verification code.
3. DNS of zwa.la: no other record on the name ciburst, a CNAME ciburst to ciburst.gitlab.io, a TXT _gitlab-pages-verification-code.ciburst with gitlab-pages-verification-code=<code>.CheckDeploy, Pages, Domains reads Verified; https://ciburst.zwa.la answers with a Let's Encrypt certificate.

Going public

Once, for 1.0.0 (D70, D72, D74). The maintainer's personal address, the noreply address and the private project names live in .local/history-rewrite.txt and .local/mailmap (gitignored), never in the repository.

1. Readiness: the policy files are on main; the project has its description (Settings, General) and is a CI/CD Catalog project (Settings, General, Visibility); main is green.CheckBuild, CI/CD Catalog lists ciburst/ciburst without versions.
2. Rewrite: in a fresh git clone --mirror, git filter-repo --mailmap ../.local/mailmap --replace-text ../.local/history-rewrite.txt --replace-message ../.local/history-rewrite.txt; keep filter-repo/commit-map.Checkgit log --all --format='%ae%n%ce%n%(trailers:key=Signed-off-by,valueonly)' | sort -u prints only the noreply address and an empty line; git log --all -i --grep and git grep -i over git rev-list --all find none of the names in .local/history-rewrite.txt; git diff <old main> main is empty.
3. Push: force push allowed on main (Settings, Repository, Protected branches), git push --force origin main from the rewritten clone, force push disallowed again; then Settings, Repository, Repository maintenance (/-/settings/repository#cleanup), the last card Repository cleanup: Upload commit-map file, Start cleanup. It drops GitLab's internal references to the old commits; GitLab mails the new size when done. Every working clone is cloned anew.Checkgit ls-remote origin main names the rewritten head; GET /projects/:id/repository/commits/<sha> answers 404 for every old commit of commit-map (one request at a time: parallel requests meet 429).
4. Release 1.0.0 (section Release) while the projects are still private, so the demo can be tested before anyone sees it.Checkthe release lists the four binary links; the registry holds cli:1.0.0; Build, CI/CD Catalog shows 1.0.0 to members.
5. Demo history (D74), after the release because it includes @1: a fresh repository with two commits, a plain project on GitLab's hosted runners, then Adopt ciburst; force push as in step 3; delete its old pipelines (DELETE /projects/:id/pipelines/:pipeline_id); Repository cleanup with a commit-map of its old commits, <old sha> 0000000000000000000000000000000000000000 per line below the filter-repo header line.Checkevery old commit answers 404 as in step 3; the pipelines page lists only the new head's pipeline.
6. Demo setup: ciburst-setup, then ciburst-check, in the demo's new pipeline.Checkboth jobs run the image cli:1.0.0; the check prints every job matches its lanes and the VM runner; the other jobs pass on ci-<project id>-vm and the demo's lanes.
7. Visibility, all at once: the group ciburst first (a project cannot be more visible than its group; other projects in it stay private), then ciburst/ciburst with the container and package registries visible to everyone with access, then the demo with public pipelines on.Checkwithout a session, https://gitlab.com/ciburst/ciburst opens, its catalog page shows 1.0.0, docker pull registry.gitlab.com/ciburst/ciburst/cli:1.0.0 works, and the README's link opens the demo with its pipeline and job logs.

VM runtime and the sweep

Rules: spec sections 6.1, 6.2 and 6.8.

• cloud-init writes /etc/ciburst/vm.env, downloads gitlab-runner 18.11.4 from the runner object and the agent from the agent object, checks each SHA-256, then starts ciburst-vm-agent.service (Restart=on-failure, 5 s).
• The agent reports on every change and at the latest after the answer's nextReportS (15 s while VM jobs queue, 30 s while busy, else 600 s); a failed report is retried every 5 s without limit. After the drain it posts /terminate, retried for 10 minutes (2 s doubling to 60 s); then it exits 1 and systemd restarts it.
• A slot that pulls its job's image has no labelled container yet and counts as free, 10 to 50 s per job.
• Tags: ciburst-state:<state>, ciburst-free:<n>, ciburst-seen:<unix time> and, once draining, ciburst-drain:<unix time>, beside ciburst, <name>, runner:<vm tag> (pool:<vm tag> on a server started before D66), job:<id>. Read them in the console (Instances, the server, Tags) or with GET https://api.scaleway.com/instance/v1/zones/<zone>/servers?tags=<name> and the header X-Auth-Token: <secret key>.
• The cron <name>-sweep runs at minutes 0 and 30 (UTC) and ends a VM older than 24 hours, a VM that has not reported 10 minutes after its creation, and a VM whose last report is more than 30 minutes old. A VM that reported within 30 minutes and is younger than 24 hours stays.

End a VM by hand, when the sweep does not:

1. Find the server: console Instances filtered by the tag <name>, or the GET above.Checkits ciburst-seen is older than 30 minutes, or no VM job runs on it in GitLab.
2. Terminate it: console, the server, Delete with its volumes; or POST https://api.scaleway.com/instance/v1/zones/<zone>/servers/<server id>/action with the body {"action": "terminate"}. Never poweroff from inside the VM: standby is billed as running.Checkthe server is gone from the list and no IP of it remains under Flexible IPs.
3. A job that ran on it fails once GitLab stops receiving its updates; re-run it.

Burst grouping

Rules: spec section 6.3. The function writes and lists intents with the cache key; a read follows at most 20 pages of 1000 keys.

Inspect the VM runner's intents:

1. Console: Object Storage, bucket <name>-cache-<project id>, folder ciburst/intents/<vm tag>/.
2. CLI with CIBURST_CACHE_ACCESS_KEY and CIBURST_CACHE_SECRET_KEY from the outputs as the key pair: aws s3api list-objects-v2 --endpoint-url https://s3.<region>.scw.cloud --region <region> --bucket <name>-cache-<project id> --prefix ciburst/intents/<vm tag>/ --start-after ciburst/intents/<vm tag>/<unix seconds>.Checka cold burst of N jobs at slots S shows N keys within about 2 s and ceil(N / S) new servers.
3. Never delete intents by hand. A key outside the format is ignored; a forged key in the format costs at most one VM-hour.

Warm start (spec section 6.5): a warm intent is <unix seconds>-warm-<pipeline id, 20 digits>, and the pipeline's records live in ciburst/intents/_pipelines/<pipeline>/ (vm-jobs.json; earlier versions also wrote seen/<job>) until its final status, which writes ciburst/intents/_closed/<pipeline>. Check: after a pipeline event with VM jobs vm-jobs.json exists; after the pipeline the folder is gone.

Known limits, each at most one VM-hour: a VM created in the 2 to 3 s after its intent left the 30 s window counts neither as old nor by rank, so a new burst at that instant can pass maxRuns by one; a repeated delivery within the same second is not recognised as a duplicate.

Queue first

Rules: spec section 6.4.

• A VM job that finds every slot busy answers queued and waits; the slot that frees first takes it. A VM starts for it only when its wait plus the expected remainder of the running job it waits for would pass vm.maxQueueS (default 90 s), or when no running job will free a slot; queue_started logs those starts. "maxQueueS": 0 starts a VM at once.
• Typical durations come from the job events: ciburst/intents/_stats/<key>/<16 hex> holds {name, typicalS, runs} per job name, the key being the VM runner's tag or a lane key. A new job name counts as ending now until it has finished once.
• Queue state in the cache bucket: ciburst/intents/_queue/<vm tag>/<job> (waiting), _running/<key>/<job> (running), _queue/<vm tag>/.started (start marker, 15 s). Never edit them by hand; entries older than 30 minutes (waiting) or 24 hours (running) are dropped when read.
• Busy VMs report every 30 s, every VM every 15 s while VM jobs queue; each report re-evaluates the queue.
• Check the queue: aws s3api list-objects-v2 ... --prefix ciburst/intents/_queue/<vm tag>/ with the cache key (section Burst grouping).

Lanes

Rules: spec section 7. A lane is one project's Serverless Jobs definition for one image and size: a job that needs no Docker daemon runs in the lane's image, billed per second.

Add lanes to a project:

1. Proposal: ciburst check --suggest (developer path: --config .local/config.json).Checkexits 0 and prints, per project and image of the Docker-free jobs on the VM runner, a lane for lanes and the tags: line of each job.
2. Config, in the project's own ciburst.json (the host's, or a member's):

   {
     "lanes": [
       { "tag": "node24", "image": "node:24-bookworm-slim", "jobs": ["lint", "typecheck", "unit-*"], "vcpu": 2, "memoryMiB": 4096, "maxRuns": 10 }
     ]
   }
   

   jobs: job names with * (any characters) and ? (one character); a pattern belongs to one lane. image: linux/amd64 with /bin/sh and coreutils or BusyBox (base64, sha256sum), pullable without credentials (section Private lane images).Checkin the host ciburst plan lists job definition <name>-<project id>-node24 and the runner <name>-node24.
3. Jobs: tags: [<lane tag>], and image: exactly the lane's image:

   lint:
     image: node:24-bookworm-slim
     tags: [node24]
     script:
       - npm ci
       - npm run lint
   

   Check: ciburst check reports no problem.
4. Host: ciburst apply, or ciburst-setup. Member: ciburst-join.Checkthe project's Settings, CI/CD, Runners lists <name>-node24 with the tag node24; a lane job's delivery answers started with runner node24 and kind lane, and the job passes.

Lane bootstrap

Every lane run executes crates/core/src/lane-bootstrap.sh (spec section 7.3) as the image's user:

Then it downloads gitlab-runner from CIBURST_RUNNER_URL to /usr/local/bin ($HOME/.ciburst/bin when that is not writable), checks it against CIBURST_RUNNER_SHA256, unsets the token and cache keys and execs run-single with the shell executor (bash, else sh) and the image's PATH as a job variable, builds in /builds, cache in /cache; a non-root user builds in $HOME/builds and caches in $HOME/cache, without a writable home under /tmp.

Try an image before it becomes a lane, from the repository root:

1. Dry run with every capability dropped, as in the sandbox:

   docker run --rm --platform linux/amd64 --cap-drop=ALL --entrypoint /bin/sh \
     -e CI_SERVER_URL=https://gitlab.com -e RUNNER_TOKEN=dry -e CIBURST_RUNNER_URL=dry \
     -e CIBURST_RUNNER_SHA256=dry -e CIBURST_LANE_DRY_RUN=1 \
     -v "$PWD/crates/core/src/lane-bootstrap.sh:/lane.sh:ro" <image> /lane.sh
   

   Check: the output ends with the gitlab-runner run-single command line, --token [masked] included; otherwise a ciburst-lane: line names what fails (section Failure modes).

Private lane images

Serverless Jobs pull without credentials, so a lane image is public or lives in the deployment's registry namespace.

1. Host config: "provider": { "type": "scaleway", "region": "<region>", "registry": true }, without the lane yet; the owner key needs ContainerRegistryFullAccess. ciburst apply.Checkthe output CIBURST_REGISTRY_ENDPOINT names the namespace.
2. Push the image to <CIBURST_REGISTRY_ENDPOINT>/<image>:<tag> with a Scaleway key that may write to the registry.Checkthe console lists the image under Container Registry, namespace <name>.
3. Add the lane with that image, give its jobs the same image:, then ciburst apply (a member: ciburst-join). A job definition is refused while its image is missing.Checkciburst plan prints only noop.

Run-single flags of lanes

Source: gitlab-runner run-single --help in gitlab/gitlab-runner:v18.11.4 (images/test/runner-help.sh) and commands/single.go at v18.11.4; every flag below is present there.

Job containers on VMs: the Docker executor labels build and service containers with com.gitlab.gitlab-runner.job.id (executors/docker/internal/labels/labels.go), which the agent counts. A runner whose requests fail waits NotHealthyCheckInterval (300 s) between requests (common/consts.go).

Failure modes

Acceptance drill

Config: the VM runner vm (slots 2, maxRuns 4) in a zone with quota, the host lane ci (image node:24-bookworm-slim, jobs ["fast-lane"]) and "ignoreJobs": ["hosted"]. Pipeline: test/drill/gitlab-ci.yml as the .gitlab-ci.yml of the drill consumer's branch ciburst-drill.

1. ciburst apply, then ciburst plan.Checkonly noop; the security group <name>-vm, the cron <name>-sweep, the agent object, the runner object and the definition <name>-<project id>-ci exist.
2. ciburst check --ref ciburst-drill.Checkevery job matches its lanes and the VM runner.
3. Cold pipeline: push an empty commit to ciburst-drill while no VM runs.Checkthe five VM jobs start three VMs (deliveries started three times, grouped twice, or warm with started and claims); node, rust, postgres, dind and docker-build pass on the runner <name>-vm, fast-lane in a lane run on <name>-ci, hosted on a GitLab runner with its delivery ignored, reason ignore_jobs; $CI_REGISTRY_IMAGE/ciburst-drill:<short sha> exists.
4. Tags while the pipeline runs.Checkstarting, then idle or busy with ciburst-free and a fresh ciburst-seen.
5. Warm pipeline within the VMs' paid hour.Checkclaimed or queued for every VM job; no new server.
6. Drain.Checkeach VM reports draining at minute 55 of its hour and is gone before minute 60; no server, IP or volume remains.
7. Sweep: in the VM zone create a powered-on server without user data, tagged ciburst, <name>, runner:vm, ciburst-state:starting.Checkthe first sweep after its tenth minute terminates it; reporting VMs stay.
8. A member: a second project joins with its own lane (section Fleet members) and runs a pipeline.Checkits VM jobs share the host's VMs, its lane jobs answer runner <lane tag> with kind lane; ciburst-leave removes its definitions, runners and webhook.
9. Cost on the consumption page.CheckInstances, IPv4 and local SSD for the VM hours only; Serverless Jobs inside the free tier.

Measured

Decisions