# SuperCI changelog, versions 0.19.8 to 0.18.1

What changed in each version of SuperCI, newest first. Every version in one file: /changelog.md

## 0.19.8 — 2026-10-16
- A run from a computer starts its machine while its working tree is still being sent (its checkout waits for the rest), and the machine fetches the tree's parts at once, each into a file: a connection that stalls is dropped after 10 seconds and the part asked for again from its start (one fetch took 69 seconds where the one before took 1). The checkout says how long each part took, and how much of it was the control plane's answer.
- `superci runs create` says how a job's start went once it runs (AWS's answer, the machine switched on, its boot, its runner), and `--dry-run` checks the workflow, its job and the working tree and starts nothing: it started a real run.
- `--tests` reads test runners whose lines are marked by the process they came from (`[slot 2] …`, several at once) apart from one another and adds them up: a failed Playwright test in such lines was missed. A failed job none of whose tests is read as failed says so, with how to get its whole log.
- A job's whole log has every step's lines: a step whose own log never came (its runner did not send one) was left out, with its test results. `--tests` keeps each failure's whole error (an assertion's diff was cut to its first lines), and says when a test runner found no test matching what was asked (Playwright's `file:line` must be a test's first line).
- `superci runs create --quiet` says what each job's tests came to (passed too), each failed test with its whole error, and a job's end after its last lines (some came after it).
- A test runner that ran no tests is said, in a run that passed too (a `file:line` that no longer points at a test, where no tests found is allowed: `[slot 2] Playwright ran no tests.`). `--tests` and `--quiet` list the tests that ran when there are 30 or fewer, a test marked to fail (`test.fail()`) that failed as a pass ("failed as expected", where Playwright marks it ✘) and one that passed when run again as flaky; `runs retrieve --tests` reads passed jobs too.
- A script finds a run's job without reading text: `superci jobs retrieve --run=ID [--job=NAME] --out=job.log`. `runs create` says each job's id, with the command for a failed one's whole log, and with `--json` a failed run gives its jobs and their ids beside `"ok": false` (it gave only the error).
- Cancelling a run from a computer runs a waiting job whose `if` holds after a cancel (`always()`, `cancelled()`) once what it needs has ended, as GitHub does; the rest end cancelled (all waiting jobs ended at once).
- Modal's machines have what GitHub's own runners have and common actions use: xz and zstd, zip, jq, git and a C compiler (setup-zig could not unpack Zig).
- A run from a computer's job on Modal or Cloudflare is told its cache has no entry as GitHub's cache says it, at once (the cache's client asked again five times each way, about a minute for each cache step), and upload-artifact is refused there saying why.
- AWS machines keep ports 50000-59999 for a job's own servers: the machine's own connections took one now and then (Supabase's local stack failed to start on a port in use).
## 0.19.7 — 2026-10-16
- A dashboard page asked for often (several tabs open, say) shows what changed within seconds: it showed the reading it had when the page was first opened, for as long as it was asked for every second or two.
- `superci runs cancel ID`, and Cancel run on a run's page: a run from a computer stops as GitHub's Cancel stops one (its jobs not started end; a running one's runner is told to stop, with five minutes for its steps, then its machine ends); a GitHub run is cancelled by GitHub, asked with your App's token.
- The cache's list names a run from a computer's repository (it showed an id such as `local-f34a…`), and `superci caches delete --repo=` takes that name.
- `superci jobs retrieve ID --tests` says where a job's artifacts are when its log has no test results too.
- An organization removed on Repositories says there what is left to do on GitHub (delete its App): it was said only on another page.
- After a move to another control plane, the dashboard stopped answering on its Control planes page (it waited for itself); it shows where everything moved.
- When AWS refuses a sign-in's last step (an account changed on its page midway), its page has Sign in again, which starts over signed out of AWS first (it sent you back to the dashboard).
## 0.19.6 — 2026-10-16
- A run from a computer whose job's spot machine AWS took back starts that job again at once, off spot machines, and goes on (it failed before, though its job said it would run again).
- Runners is one list in order: AWS spot, AWS on-demand, Cloudflare and Modal are alike rows, each with jobs at once, a monthly budget and where it starts machines (AWS's on-demand machines now have regions of their own, like its spot ones). Any row can be taken out of the order and put back, its settings kept; `superci runners order` takes out the ones it does not name. The accounts (AWS's own network, Cloudflare's image, removing one) are under Clouds.
- Runs from a computer run a job that calls a workflow of the repository (`uses: ./.github/workflows/x.yml`) as GitHub does: its jobs (`caller / job`), with the inputs and secrets the caller gives (`with:`, `secrets: inherit` or named), and its outputs for the jobs that need the caller. (One of another repository is not run from a computer yet.)
- Runs from a computer run steps side by side as GitHub does: `background: true`, `wait`, `wait-all`, `cancel` and `parallel` groups, refused where GitHub refuses them.
- A GitHub job whose steps ran side by side shows each step's own lines on its page, from its run's logs once the run has ended (until then its lines are in the order they came, and the page says so).
- On AWS and Modal control planes, a job's Raw log opens GitHub's own link again, whatever its size.
- With several workspaces on the computer, dragging Runners into a new order saves it, instead of putting it back as it was.
- With several workspaces on the computer, `superci login cloudflare` and `superci login modal --workspace=ID` open that cloud's sign-in in the workspace named, and a page that leads to a part of another one (Control plane's AWS account, its Permissions) stays in the workspace it was opened in.
- `superci login aws --workspace=ID` with several workspaces on the computer: Continue to AWS goes on to AWS, instead of a page asking which workspace.
- A matrix made by an expression (`${{ fromJSON(needs.setup.outputs.matrix) }}`) is read once the jobs it needs have ended, as on GitHub.
- A job's `timeout-minutes` ends it once it has run that long, and its `continue-on-error` lets the run go on when it fails (the jobs that need it see a success, as on GitHub).
- Runs from a computer read YAML anchors and aliases in workflow files, as GitHub Actions does; a merge key (`<<`) is refused, as GitHub Actions refuses it.
- `superci runs retrieve ID --tests` (and `superci jobs retrieve ID --tests`): each failed job's tests, read from its whole log: the tests that failed, each with its file and error, how many passed, failed and were skipped, and where its artifacts are. It reads what Vitest, Jest, Playwright, pytest, cargo and Go print. For a coding agent: what failed, without reading the log.
- A large log's page is quick: a step's lines are drawn when it is opened, 2,000 at a time (Show more), search looks through the log itself and shows the lines that hold the words, and a finished job's log is kept for its next opens.
- An AWS sign-in that AWS does not finish (seen when the account is changed on its page midway) says so plainly, with the way back to the dashboard to sign in again, instead of AWS's raw error.
- When the control plane's cloud sign-in has ended (AWS ends one after 12 hours), the update card's button signs in first and comes back, instead of an Update that stops on "Sign in with AWS first".
- Runs first in the dashboard: Overview lists the latest runs, and its first figure counts runs, with their jobs beside it (from a control plane on 0.19.6, which also counts the runs of the jobs it kept from before, once, in its upkeep; jobs until it is updated). The sidebar's Jobs is Runs, its Runs tab first.
- A job sent on-demand by the AWS account's spot limit says when machines SuperCI had just ended still counted ("machines AWS was still ending count too"): AWS counts a machine for a minute or two after its job ends.
## 0.19.5 — 2026-10-15
- A job on AWS says the CPUs of the machine it got: one that asked for 128 on c8a (which has no 128-CPU size) got a 192-CPU c8a.48xlarge, and said 128.
- AWS machines above 64 CPUs are asked in each family's own sizes: the 128-CPU size where a family has it (c7a, m7a, r7a, and the families with a local disk), and no size a family lacks (c7g, m7g and r7g end at 64; c6id, m6id and r6id at 128).
## 0.19.4 — 2026-10-15
- A finished job's page shows its whole log, whatever its size: a GitHub job's from GitHub, a run from a computer's from the bucket. It read only the last 1 MB, so a large log's first steps looked empty. A log that is still cut (a running job's, or one from a control plane older than 0.19.1) says so.
- `superci jobs retrieve ID --out=FILE` says when the control plane gave only the end of a log, instead of keeping that as the whole.
- `superci runs create --quiet` prints how each step went and the last lines of one that failed, not every line: for a coding agent, whose every line read costs. `--detach` says the run's id and ends; `superci runs wait ID` follows it. Every run now ends with its steps' results and times, its machine and what it cost.
- A run from a computer's page in the dashboard lists its artifacts, each a download.
- A job's whole log, whatever its size: `superci jobs retrieve ID --out=FILE`, and the dashboard's Raw log, take a run from a computer's from its pieces in the control plane's bucket, and a GitHub job's from GitHub (4 MB at most before).
- Windows machines say how their start went (boot, start-up script, the runner), try the runner's addresses at GitHub before starting it, and send its lines as they are written, as Linux machines do.
- AWS's limit on CPUs at once is asked for more of from one button, with spot and on-demand apart, each with its limit now.
- `superci projects list` without GitLab says so; amounts with nothing spent say 0, not -0.
- A run from a computer says why a job failed when no machine began it ("Cloudflare did not start a machine for it, three times"), and a job ended for running past its longest time says so, there, in `superci jobs retrieve` and in the dashboard.
- A job that ran and failed is no longer said to have not started, on the Jobs page and on its page.
- Saving the default machine returns to Workflows, where it is set. `superci runners update CLOUD --enabled=false` is refused for a provider other than aws-on-demand (it did nothing): another is removed with `superci runners delete CLOUD`.
## 0.19.3 — 2026-10-15
- `superci runs create` no longer goes quiet: after a burst of lines GitHub's runner did not send as fast as they came, 0.19.0 waited for the step to end before it printed more of it, minutes for a long step. What was dropped is now filled from what the machine sends of the step's own log every two seconds, and the lines go on as they come; the few the runner still holds come when the step ends, said as such.
- A runner's lines are kept as they come, with nothing else read or written each time (each post of a hundred lines rewrote the job's whole record).
- `superci jobs retrieve` shows a step still going from what its machine sent of the step's log, not only the lines the runner sent as it went.
- The ids of runs from a computer are below 2^53, so GitHub's actions print them whole ("Artifact download URL" had the run's id rounded).
## 0.19.2 — 2026-10-15
- `superci runs create` and `superci caches delete` go on when SuperCI's cloud sign-in has ended, or another account is signed in: they need only this computer's key with the control plane it is kept for, as looking at jobs, runs, usage and artifacts already did. (AWS ends its sign-in after twelve hours, and when you sign out of the AWS console to sign in to another account.) Changing a control plane's settings still needs a sign-in to the cloud account it runs in, and says so.
## 0.19.1 — 2026-10-15
- A GitHub job's page shows its lines while it runs. GitHub gives a job's log only once it has ended; its machine now sends what the runner writes of each step as it goes (every two seconds, in the pieces the runner writes them), kept in the control plane's bucket until GitHub's own log is there. A step that writes little shows its lines when it ends.
- Runs from a computer send only what changed since the working tree this computer last sent whole (kept in the control plane's bucket as a base): a few files' worth instead of the whole tree, for an agent that runs the tests after each edit. The machine puts the base in place, then the changes, and removes what was removed. A base gone (the bucket keeps it up to a month), or changes of half the tree or more, and the whole tree is sent again.
- A job's log is given up to 4 MB (1 MB before) by `superci jobs retrieve --bytes` and the dashboard, and a GitHub job's Raw log comes whole, from GitHub itself, whatever its size.
- A control plane on Modal keeps each kind of record in a Dict of its own, so looking up one kind no longer reads every record; what it kept before is moved over by itself.
## 0.19.0 — 2026-10-15
- `superci runs create` prints every line of a run's jobs. GitHub's runner sends its lines as it goes only as fast as it can, holding 1,024 at most and dropping the rest, so a job that printed a lot (an e2e suite's 5,000 lines) was cut short though it passed. Each step's whole log, which the runner sends when the step ends, is now kept (in the control plane's bucket, where there is one) and what was dropped is printed from it, in order. The dashboard's log of such a job is the whole one too.
- The control plane keeps its records apart by kind (on AWS, a DynamoDB partition for each), so one kind's traffic never slows another's; what an earlier version kept is moved over by itself, a little at each minute's sweep, with nothing to do.
- Starting a machine, the minute's sweep and the dashboard read only the jobs still going and each day's totals, not every job ever kept, so they stay as fast with a year of history as with a day's. Spend, limits and usage come from each day's totals.
- Records end by themselves: a job's 90 days after it ends (about two months before), its lines and logs after two days, a machine's start record with its job, cache entries with their pieces in the bucket.
- A job's log in the dashboard is in steps, as GitHub shows one: how each step went and how long it took, its lines numbered and in colour, a step's errors and warnings marked and counted, the step running (or the one that failed) open. A GitLab job's steps are its sections, by GitLab's own headings. While the job runs the log reads on by itself and adds what is new where you are, rather than drawing the page anew (which put the log back at its top). Search it, show each line's time, or take the raw log.
- A runner of GitHub's whose first connection GitHub refused waited 30 s before it tried again (GitHub's runner waits that long), so its job started half a minute late. The machine now tries the runner's addresses at GitHub first, every second, beside reading the runner's files, and starts the runner once they answer: a refusal costs as long as it lasts. A job's start says so ("GitHub refused the first connection; reachable after 3 s"). The start-up script also leaves out its explaining lines, so it stays well within what AWS takes.
- `superci status --json` says how the control plane's store stands (`store`: its jobs indexed, nothing left in an earlier layout).
## 0.18.2 — 2026-10-14
- Overview's figures cover the last 24 hours, 7 days or 30 days (a switch on the card), counted by the control plane over every job it keeps, not from the latest fifty: jobs, machine minutes beside the minutes GitHub or GitLab would bill (each job rounded up to a minute), the wait for a machine, and what they cost beside what the code host's own runners of the same sizes would have charged, with what that saved. `superci usage retrieve --period=day|week|month` says the same. The page waits in the same shape while it loads.
- A run from a computer with a working tree of many MB failed before it started: the tree went into the control plane's DynamoDB table, which writes only so much a second, and DynamoDB refused it ("ThrottlingException"). The tree now goes into the control plane's bucket in one piece, as a build service takes its source, and its machine fetches it from there; a tree may be 1 GB packed (150 MB before). A control plane with no bucket takes it as before.
- The control plane on AWS asks DynamoDB again when it says it is too busy, waiting a little longer each time, as AWS's own tools do, rather than fail at once.
## 0.18.1 — 2026-10-14
- What a run from a computer's jobs keep with `upload-artifact` can be fetched to the computer: `superci artifacts list --run=ID` names them, `superci artifacts retrieve NAME --run=ID [--out=DIR]` unpacks one, as `download-artifact` would. With a key that only reads too.
- A key for coding agents has no limits of its own: its jobs keep to the control plane's, as every job does (the largest machine, what may be spent in a month and a day). `superci keys create agent --runs` takes no `--max-cpu` or `--daily-usd`; a key made by 0.18.0 is no longer taken, so make it again.
- `superci runs create` against a control plane older than 0.18.0 says to update it, rather than that the control plane has nothing there.