A Settings page, below Control plane in the sidebar: the name, the labels and the limits (largest machine, longest job, public repositories) moved there from Workflows, and so did signing out, which was under More. Workflows keeps the default machine and how to use your label.
Many jobs queued at once no longer leave a machine idling and a job called failed that passed. GitHub gives a waiting job to any idle runner with its label, so jobs often run on each other’s machines; with three or more passing theirs around, the control plane could start one machine too many, let it idle for ten minutes, and then say “Its machine never started the job” of a job that had run elsewhere (seen with 16 jobs at once). No such machine is started now; a machine that ended with another job’s work keeps its cost in the list; and a machine nobody waits for is ended at the first sweep after it had time to come up (a minute and a half on AWS), not after eight to ten minutes. Before ending one, the control plane asks GitHub whether its runner is busy, and a job that still waits with no machine coming gets that one.
A burst of launches that AWS refuses for their rate (“RequestLimitExceeded”, seen from the eighth job of a burst on) is asked again within the same seconds. Before, those jobs waited for the next sweep, up to two minutes.
A control plane in AWS sweeps every minute (before: every two). superci planes update changes the schedule.
A job that ran on an on-demand machine because spot was refused says so, in its row and in superci jobs list: “On-demand: your AWS spot limit in N. Virginia was reached”. When that happened in the last day, a line above the jobs says how many, with the link to ask AWS for more. Before, only “on-demand” beside the machine showed it, at about twice the price.
superci login aws opens on a page of SuperCI’s with one button to AWS. When AWS answers “400 Bad Request” (an old AWS sign-in in the browser is in the way), Back comes to that page again, which then offers to sign out of AWS and try again.
Labels of your own. Your control plane answers to a list of labels, superci alone to begin with: add one on Workflows → Labels, or with superci labels create acmeci, and workflows can name it in runs-on (runs-on: acmeci, acmeci/cpu=8/arch=arm64). Every label in the list works at once, so workflows change one at a time and nothing waits the day you add one; remove a label when nothing names it any more. The one added last is the one shown in examples. Two to twenty-four lowercase letters and digits.
A name of your own. Workflows → Name, or superci name update AcmeCI: the dashboard’s header and tab say it, a GitHub App made for a further organization starts with it (AcmeCI acme …), GitLab’s runners are described with it, and a job that could not be run says “AcmeCI could not run this job”. SuperCI puts it back. The command stays superci.
A move to another control plane takes the labels and the name along.
Installs without Node too, as the same program: brew install supercorp-ai/tap/superci, curl -fsSL https://superci.dev/install.sh | sh (macOS and Linux; checked against npm’s checksum, put in ~/.local/bin), or cargo install superci. Then superci dashboard.
A job that GitHub never told your control plane of now gets its machine all the same. GitHub sends each event once, and can lose one (seen: a job queued four seconds after a move changed the App’s address was never sent anywhere, so it waited until cancelled). The control plane now asks GitHub which jobs wait for its runners: every five minutes for the repositories that had a job in the last day, and every sweep in the quarter of an hour after a move.
After superci planes move, commands read the control plane moved to at once (before: the one moved away from, until superci planes list or the dashboard had looked again).
superci github_deliveries list and retrieve ID show what GitHub says of the events it sent your control plane: when, what, how each was answered, and for one, which job, which address and what was answered. For a job that never got a machine.
superci planes create, with a control plane in use already: the new one no longer takes its place in what SuperCI keeps on your computer. In 0.11.0, commands run afterwards went to the new, empty control plane until the dashboard was opened again.
After AWS has ended a sign-in that was SuperCI’s only one, the dashboard and the commands that look go on working at the next start too (in 0.11.0 only until the program ended), and a change says that the sign-in has ended and to run superci login aws.
A move to another control plane waits until the new one says every runner provider it was given is there, before GitHub and GitLab are switched over. Before, a job that arrived in the first minute could fail saying a provider was not added (seen with Cloudflare’s containers).
A command that would delete something and was not given --confirm says only that, without its resource’s help after it.
superci login says what it is waiting for and that it is done, without a line for each request of the browser.
SuperCI stays signed in. Its sign-ins to your clouds are kept in its own folder on your computer (~/.superci, readable by you alone), so the dashboard opens where you left it. An AWS sign-in still ends after twelve hours at most, as AWS has it; Cloudflare’s no longer ends after an hour.
Everything the dashboard does is also a command, for scripts and coding agents, in the shape of Stripe’s CLI: superci <resource> <operation> [id] [--param=value], with list, retrieve, create, update and delete wherever they fit. The resources: jobs, planes (also move and allow), runners (also order), machine, limits, public_repos, github, gitlab, gitlab_projects and keys; beside them superci status, login, logout, dashboard and leave. A command runs the same code as its page. --json prints one object; --dry-run checks a change and says what it would do; nothing is ever asked in the terminal; what would delete something needs --confirm; when a person is needed first (a sign-in), the answer names the command for it and the status is 3.
The dashboard opens with superci dashboard (npx @superci/cli dashboard). superci alone lists the commands, and superci help RESOURCE (or superci RESOURCE --help) says more about one.
superci login [aws|cloudflare|modal] signs in, in the browser, and ends; superci logout removes the sign-ins from this computer, asks Cloudflare to end its one, and has the control plane forget this computer’s key. The dashboard’s sidebar has the same under More → Sign out.
After an AWS sign-in has ended, the dashboard still opens on your control plane and shows its jobs and settings (read with this computer’s key), with a line saying the sign-in ended and a button to sign in again. Before, it would have shown the first screen as if nothing were known.
SuperCI reads no other tool’s credentials. CLOUDFLARE_API_TOKEN, MODAL_TOKEN_ID and MODAL_TOKEN_SECRET are no longer picked up; on a machine with no browser a sign-in is given by name: SUPERCI_CLOUDFLARE_TOKEN, SUPERCI_MODAL_TOKEN_ID, SUPERCI_MODAL_TOKEN_SECRET.
The key the dashboard reads a control plane with lasts thirty days and is reused between runs (before: a new one, twelve hours, at every start).
Keys that only read, for a coding agent or a script that should look and not change: superci keys create agent shows one once; with SUPERCI_PLANE and SUPERCI_KEY set, whatever looks (superci status, superci jobs list, superci jobs retrieve ID…) works with no sign-in on that machine, and nothing can be changed. Your control plane keeps only the key’s SHA-256; a key ends by itself (30 days unless said otherwise) or with superci keys delete.
superci jobs retrieve ID shows one job with the end of its log: GitHub’s, read by your control plane with your App’s token, or GitLab’s. So why a job failed can be read without opening the code host.
A change is seen at once on a control plane in AWS (before: up to fifteen seconds later, while it went on with the settings it had read). The dashboard and commands no longer wait there after each change, and a change made right after another starts from it.
A job may run for six hours, as on GitHub’s own runners (before: 70 minutes). Limits has a new setting, Longest job (superci limits update --max-hours=N), for another length: up to five days on AWS (the longest GitHub lets a job run on a runner of your own), a day on Modal; Cloudflare keeps a container six hours at most. A job’s machine is ended at that limit, also when the control plane is gone.
A release becomes what npx @superci/cli gives only once every one of its files downloads from npm, the launcher’s too (npm lists a version minutes before it serves its file; for those minutes a new install failed).
The dashboard has a new mark: four petals, as on superci.dev, in place of the two arrows.
SuperCI is released by its repository on GitHub: one workflow builds the program for macOS and Linux (Apple silicon, Intel, arm64, x64), runs the tests, tries it through npx, and publishes @superci/cli to npm, which trusts that workflow (trusted publishing). No person’s npm login or token is part of a release.
Nothing changes in the program or in a control plane.
Docker works in jobs on AWS: service containers, container jobs and docker steps. The machine image left Docker to root, so these failed; the runner’s user is now let in before the runner starts, and Docker starts beside it.
A GPU job in an AWS account that is allowed no GPU machines fails at once saying which allowance to raise, also when spot machines were refused for another reason (before: after three tries, with “AWS had no room”).
Back from creating and installing the GitHub App, the dashboard reads your control plane fresh and keeps looking until it says the App is installed (a control plane takes a few seconds to see what was just stored). Before, Overview could go on saying “Connect repositories” after GitHub was connected.
A page shown from what the dashboard read a moment ago looks again once that has been read anew, so it does not stay on what was true before.
Set up on Overview does nothing in place: each step says where it stands in a line and has one button to the page where it is done (Set up control plane, Connect repositories, Add runners, Open Workflows).
Deploying a control plane has its own page, Setting up your control plane, with its steps; when it is done you are back on Overview. Overview says a deploy is running in one line, with a link there.
The deploy’s steps say what each one is (its permissions, its storage, its check for waiting jobs and leftover machines every 2 minutes on AWS).
Runners: the AWS on-demand row says “one per job, never interrupted”. Like every machine, an on-demand one is ended when its job ends.
Before there is a control plane, Overview is the page it will be: Set up with its first step open (one button, Set up control plane) and the steps after it in one row, then the day’s figures and the latest jobs, still empty.
An Overview with no jobs yet shows the same shapes at zero instead of one line.
Dark mode is darker: near-black with neutral greys and white text, as on supercov.com.
When AWS has no spot machine for a job, the order of your runner providers decides what happens: the job goes to the next provider in the list that can run it. AWS on-demand is a row of its own there (Runners), right under AWS until you move it, with its own limits (jobs at once, a monthly budget) and a switch to turn it off.
The same when a provider cannot start a job’s machine for any other reason (Cloudflare or Modal failing, AWS refusing the request, a provider refusing what the job asks, like GPUs): the job goes to the next provider that can run it instead of trying the same one again. When none can, each one’s answer is said; the job is tried again twice, starting with the providers that have not failed it, then fails.
With nothing below that can run the job (on-demand off, no other provider that fits), it waits for a spot machine instead of failing.
A job run again after AWS took its spot machine back, and jobs started while spot is paused after several were taken, also go to the next provider below AWS’s spot machines (before: always on-demand).
The name is SuperCI. The program is superci, the label is runs-on: superci (with sizes: superci/cpu=8, superci/gpu=any, …), and what it makes in your clouds is named after it: control planes superci-plane-<id>, runner agents superci-runners-<id>, the GitHub App SuperCI <owner>, the tag superci-plane.
Several GitLabs on one control plane: Repositories → Another GitLab adds another server, or another account’s token on the same one, beside the first. Each is a row with its own settings (its projects, a new token, Disconnect) and its own line under Permissions; their jobs run on the same runners. Jobs and runners of different GitLabs are kept apart even when their numbers are the same.
A GitLab connection’s token can be replaced in its settings (New token) without disconnecting: the projects turned on stay on.
Control plane → Permissions reads at a glance: each row says in a few words how it stands, and when there is something to do, one Review button opens its steps (what is needed and why, then the one button or link that does it).
“Change region” beside AWS is a button, like the others in its row.
Connecting GitHub (the first organization or another) and GitLab are dialogs of three steps: where it is (the public one, or your own, which asks its address), whose jobs or which token, then the button that does it. Their rows have one button each.
AWS’s sign-in page answering “400 Bad Request” (it does when the browser holds an AWS console sign-in that has ended; AWS’s own aws login has the same fault): back in the dashboard, a notice says the two ways on: sign in to the AWS console in another tab and try again, or “Sign out of AWS and try again”, which clears the old sign-in and goes on to the sign-in.
Signing in with AWS from a Review dialog comes back to that dialog, with everything to allow.
Signed in to another AWS account than the one a control plane’s role is in: Permissions says which is which.
An AWS sign-in that has run out (they last twelve hours at most) is forgotten and asked for again, not shown as an error on every action.
After an update, while its cloud still answers with the version before (Cloudflare can take a few minutes with containers), the dashboard says “Restarting” and looks again by itself, with no Update button meanwhile.
Fixes found by a second review, of the three versions before:
A job whose runner was taken by another job gets a machine even if that other job’s machine never comes up (before, it could stay queued).
Out of time while spot is refused: the job’s next try goes straight to on-demand.
A job’s end delivered twice by GitHub no longer ends the machine kept for the job that waits; a machine left idle by a cancelled job that takes another job is not ended under it.
A network of your own set or changed in the dashboard is used by the next job, not minutes later.
Two organizations of the same name on github.com and on a GitHub Enterprise Server are kept apart.
Several jobs of one run taken back by AWS are run again together with that run’s other failed jobs (GitHub takes one request for a run’s new attempt).
GitHub Enterprise: an organization on your own GitHub Enterprise Server (3.10 or newer), or on GitHub Enterprise Cloud with data residency (yours.ghe.com), connects like one on github.com. When making its App, say where your GitHub is (Repositories → the field beside the name; empty: github.com). Its App, its jobs’ runners and every link then use that server. One control plane can serve organizations on github.com and on your server at once.
What it needs: the server can reach the control plane (it sends job events there), the control plane can reach the server’s API, and runners can reach the server (on AWS, a network of your own does that for a server inside your network).
A Cloudflare control plane hands its settings to its Durable Object in pieces, so many organizations’ Apps fit.
GitHub’s full image on Cloudflare (experimental) is checked: every piece against its SHA-256 in the image’s index; the index against the address, when the address ends in the index’s checksum; the reader program against the index. A piece that is not what the index says is never used.
An image that cannot be loaded fails the job at once saying why, and what was set up is taken down (before, the job ran in the small image, without the tools it expected).
The reader survives what goes wrong: a piece that cannot be fetched fails only the reads of it, and is tried again when read again; its cache gives way when the job fills the disk (the oldest pieces are dropped, and fetched again if read again).
image-reader pack <image file> <directory> makes what to upload: the pieces, their checksums, the hot list, the reader, in a directory named by the index’s checksum. crates/image-reader/try.sh tries all of it for real in a local Linux container.
The image’s environment (/etc/environment) is read as names and values, never run.
No room for a spot machine in any region: the job gets an on-demand one (the regions in order again) rather than waiting; its machine says “on-demand” in the job list.
Spot machines taken back: Windows machines and GitLab jobs are handled too. A Windows machine ends the job’s process so it fails at once; a GitLab job is run again by GitLab at once, on an on-demand machine. Several jobs of one GitHub run taken back are run again with one request.
Your own network on AWS: Runners → AWS → Your own network takes a line a region (subnets, security groups, private for subnets without public addresses). Machines there start in your network, so jobs reach what it reaches and leave by its NAT. A network that is wrong is said, and no machine starts anywhere else. No new permission.
Fixes found by a review of the last versions:
A job that passed just as AWS gave notice is not run again; a notice follows the machine to the job its runner took; re-runs survive GitHub not answering.
A failing runner that takes another job is said on that job, and that job’s machine takes the first.
GitLab: a runner that takes another job’s job no longer has its busy machine taken for one that never began; a job cancelled before a runner took it has its machine ended.
A machine that never began a job GitHub or GitLab no longer has waiting is ended, with none started again; a machine’s age counts from its start, not from when its job arrived.
A network that cannot be read is an error (the job is tried again), never a reason to use AWS’s default network.
Removing AWS deletes what lets the control plane start machines first, then its machines and network; a sign-in that ended is said before anything changes.
Adding an organization never replaces the first one’s App on a guess; removing one forgets it even if GitHub will not uninstall its App; a move takes every App and waits for each.
os=windows and GPU labels no longer take a default machine’s arm64 with them.