Runs. The Jobs page has a Runs tab: a workflow’s jobs together (on GitLab, a pipeline’s), with how the run stands, how long it took from its first job queued to its last one over, what its machines cost together, and the job that was over last, the one the run waited for (“Last to end: E2E (1/2), 6m 12s after 1m 5s waiting for a machine”). A run or a job run again is its own row (“attempt 2”), for jobs from this version on. Only the jobs SuperCI ran are counted. In commands: superci runs list and superci runs retrieve ID (with --json).
A control plane in AWS tries again within seconds. A job waiting for room, and a start AWS refused that is tried again, waited for the next minute’s sweep; the control plane now asks itself for one twenty seconds on. Update your control plane for it (the update gives it leave to call itself, and nothing else).
An AWS account that is its organization’s management account is said so under AWS account, with signing in to another: it is easily picked by mistake where AWS lists the sessions.
A project of AWS’s new sign-up whose region does not have the runner image yet no longer reads “Everything SuperCI does works there” beside the step that comes first: it says the image is copied in first, and the Copy the image button says it is needed before Set up and takes about ten minutes.
A job on a spot machine AWS is taking back has what is left of AWS’s two minutes to end by itself. Its runner is stopped twenty seconds before the machine goes (forty on Windows), and only if the job is still going. Before, the runner was stopped the moment the notice came: a job a minute from its end failed and was run again, where it now passes. A job with longer to go fails as before, and is run again once its run has finished.
Several jobs queued at once, in an AWS account that AWS lets ask for few machines in a moment (a new one): four of five went to on-demand machines, at about twice the price, with nothing said of why. A spot request AWS refuses for its rate is now asked again for the same pool after a wait, in place of the whole launch starting over (which spent more requests and was refused again). One still refused after its waits goes on-demand as before, and the job says so: “On-demand: AWS refused the spot request for its rate (many machines asked for at once)”.
A spot pool (a machine type in a zone) that had no machine, or took one back, is asked last for a quarter of an hour. Each job of a burst no longer spends a request on it, and the job run again after an interruption is not followed by the next job into the same pool.
The job list names each machine’s row by the job it ran. GitHub gives a waiting job to any idle runner with its label, so jobs queued together run on each other’s machines; a row was named by the job its machine was started for, and showed “E2E (2/2)” failed when it was “E2E (1/2)” on GitHub. The row’s link and superci jobs retrieve go to that job too.
The rows of the Limits card on Runners begin at the card’s edge (they kept an empty place for a handle they do not have).
A finished job is said by how the job itself ended: Passed, or Failed when its own steps failed (a test, a build), as GitHub said. Before, every job a machine had run to its end read “Done”, in green, whether its tests passed or not. Jobs from before the update keep “Done”: how they ended was not kept. In superci jobs list the same (passed, failed), and --json has it as ended beside state. Update your control plane for it.
The dashboard’s tab has an icon: your GitHub organization’s picture when the workspace has one, SuperCI’s mark otherwise.
The AWS account section reads as what it is. An account its organization keeps to some regions, with everything else allowed, says where SuperCI works (“SuperCI works there in N. Virginia”) in place of “Restricted: some of what SuperCI does there is refused”. The Runner image row says where the image is; a region the account may also use that lacks it is no warning, and has “Copy into Stockholm” beside it (before, the image could only be copied in from a terminal once a control plane was set up). A provider’s region list says where to copy it in.
An AWS sign-in that AWS ended early is seen as that. A sign-in lasts as long as the AWS session it was made from, twelve hours from when that session began; one made from a session eleven hours old has an hour. AWS then answered “expired” to ordinary calls before SuperCI went to renew, and the pages showed that as it came (“Not read: ExpiredToken…”) and the AWS account section read “Nothing refused” with nothing known. Now the sign-in is renewed or, when it is over, the pages say so with Sign in again; and a look AWS did not answer is said as “Not known”, never as an account with nothing refused. The page before AWS’s sign-in says which session to choose.
The GitHub App made for an organization is named after your CI and the organization, and nothing else: “AcmeCI acme” in place of “AcmeCI acme x1y2z3”. It is what owners read among their Apps, and what a job run again by your CI says ran it. Should GitHub say the name is taken (an App of yours from before, never deleted there), another name typed on GitHub’s page does as well. Apps made before keep their names.
A GitHub App renamed on GitHub keeps working in the dashboard: the control plane asks GitHub for the App’s address as it is now, and the links to the App (install it, its settings, its permissions) follow within ten minutes. Before, they went to the address the App was made with.
What an AWS account allows is asked again each time a page that shows it is opened (when the last look is older than twenty seconds), beside the page: a change made in AWS shows within seconds. Before, it showed up to ten minutes later. The AWS account section also has Refresh.
Removing SuperCI from an AWS account whose organization keeps it to some regions no longer reports “its machines’ network” as left behind for the regions it may not use (nothing could be made there), with AWS’s refusal in full.
A control plane deleted from AWS no longer leaves its log behind: the function’s last lines could make the log anew after it was deleted.
Daily limits, beside the monthly ones on Runners (the card is now called Limits): for everything, and for the AWS account. A day that runs away stops that day (UTC). In a terminal: superci limits update --daily-usd=N and superci accounts update aws --daily-usd=N (none lifts one).
A budget in the AWS account itself, for the account’s monthly limit: in the AWS account’s limit dialog, “In AWS itself” is nothing, “AWS emails me at 80% and 100%”, or “AWS emails me, and stops new machines at 100%”. AWS counts the account’s real bill, all of it and hours late, so it covers what SuperCI’s estimate misses. In a terminal: superci accounts update aws --aws-budget=emails|stops|none --email=ADDRESS. It is made, changed and removed with your sign-in; the control plane gets no permission for it, and a budget of your own is never touched. Changing the limit changes the budget with it; removing AWS runners or the control plane removes it.
With “stops”, at 100% AWS puts a rule on the control plane’s role that refuses new machines, and takes it off when the next month begins. A job refused by it fails on GitHub at once saying so (“AWS’s budget for this account reached its limit and stopped new machines there”): the rule lets through one kind of machine, the small one that tells GitHub why a job was refused, and no job’s own machine is ever that kind. Nothing is reported as a missing permission, and the account’s row says “Stopped by AWS’s budget” with Lift (--aws-budget=lift). Raising the limit lifts it too.
Where your AWS account holds its own copy of the runner image (a region the image is not published in), SuperCI says when its maker has a newer build out: in the AWS account section, with “Copy the new one in”, and in superci images list; superci images update REGION copies it in. Jobs start from the older copy until the new one is there, and the older one is then removed.
A deploy that stopped partway and is given up (“Choose another place”) removes what it had made in AWS. Before, its role stayed behind.
A machine type a region does not have is no longer asked for with every job (about a second each time, and a spot machine’s zone was then not chosen by price): the region is asked once what it has.
A runner is named by your CI’s name where developers read it (a job’s log on GitHub, GitLab’s runner list): acme-ci-<id>-<job> in place of superci-<id>-<job>. A CI given another name names its next runners by it.
AWS accounts that do not allow everything. SuperCI now looks at what an AWS account allows before it sets anything up there: which regions, whether spot and on-demand machines may start, how many CPUs at once, and whether the image jobs run on is in each region. It asks with reads and dry runs: nothing is made or changed by looking. Then it works with what it found. Nothing has to be changed in AWS to use SuperCI.
What it found is an “AWS account” section on the Control plane, set-up and Add runners pages, for every account, and superci accounts retrieve aws in a terminal (superci accounts list lists the accounts signed in to). A refusal says whose rule it is: a policy of your AWS organization, named, or the permissions of the role signed in as. Where regions are chosen, one the account cannot use is shown and cannot be picked, with why. A deploy to a region the account cannot use is refused in plain words before anything is made.
A project from AWS’s new sign-up, which AWS keeps to one region and allows no spot machines until its advanced features are activated, is recognised and set up in its region.
Where an account’s AWS organization allows no spot machines, a job goes to an on-demand machine at once and says why: “On-demand: your AWS organization does not allow spot machines”. Before, such a job failed. The refusal is remembered for ten minutes, so each job does not ask again, and AWS’s spot provider on Runners says “not allowed” in place of “ready”.
The image jobs run on is not published in every region (not in Stockholm or Canada). Where it is missing, the set-up page offers to copy it into your account first, then sets up: about ten minutes, and about $1.50 a month for the copy’s storage. In a terminal: superci images list, superci images create REGION and superci images delete REGION --confirm. Before, a control plane set up in such a region could start no job.
Monthly limits, on Runners: one for everything (all providers together: at it no job starts until next month or a higher limit) and one for the AWS account (its spot and on-demand machines together: at it jobs go to the providers of other accounts). Each row shows what was spent this month. In a terminal: superci limits update --monthly-usd=N and superci accounts update aws --monthly-usd=N (none lifts one). A job refused at a limit fails on GitHub saying so. Update your control plane before setting one.
Commands: a cloud or a code host is no longer a command of its own. superci connections list, create github OWNER, create gitlab --url=… and delete take the place of superci github and superci gitlab; superci deliveries takes the place of superci github_deliveries, and superci projects of superci gitlab_projects.
With several workspaces and none named, the dashboard opens on the workspace it showed last (before: on the list of them); the switcher leads to the others. After switching workspace, the sidebar’s links stay in it (before: the next press went back to the workspace the page was opened with).
A job’s machine is called by your CI’s name, the repository and the job in AWS’s console (acme-ci-web-42), in place of the control plane’s id.
A deploy that stopped offers “Choose another place” beside “Try again”.
Fixes: a finished set-up step no longer fills the screen; a page that refreshes itself leaves an open dialog, and a field being typed in, alone; just back from GitHub, the Connect button says it is connecting until the control plane has the App; a control plane that misses one answer is asked again before the page says “Not answering”.
Workspaces: several CIs looked after from one computer, each apart from the others. A workspace has its own sign-ins to its clouds, and through them its own control plane, runners, repositories and settings. Nothing of one shows in another, and signing out of one leaves the others signed in. With one workspace nothing changes and nothing needs naming.
The name at the top of the dashboard’s sidebar is the switcher: your workspaces, each with its GitHub organization’s picture once one is connected (GitLab’s logo for GitLab), and “New workspace…”, which asks what it is called (AcmeCI) and opens a clean first screen. The first control plane set up there gets that name. One dashboard serves them all; a page’s address says which workspace it is of, so two tabs can show two. A sign-in comes back to the workspace that started it. The picture also stands beside the name at the top; it is asked for from GitHub when the dashboard starts and once a day, so a logo set there later shows by itself.
A workspace has an id, made from its name (Acme CI: acme-ci): what commands take. Settings shows it, with Change, and, when there are other workspaces, “Remove this workspace”: it is signed out and forgotten on this computer, and nothing in its clouds is deleted.
Commands: --workspace=ID, or SUPERCI_WORKSPACE=ID for a whole terminal. With several workspaces, a command that names none stops, with nothing done, and lists them; an id that is none of them stops it too. Nothing picks one for you. superci leave takes the workspace from the command itself, never from the variable. superci workspaces list, create NAME, update ID --id=NEW and delete ID --confirm; superci dashboard with several and none named opens on the list of them.
Sign-ins are kept by workspace, in ~/.superci/workspaces/ID/sign-ins.json; the first workspace is default. A sign-in kept by an earlier version (~/.superci/sign-ins.json) is not read: sign in again (superci login), or move that file to ~/.superci/workspaces/default/. Your control plane and runners are not affected.
The switch between light and dark is gone: the dashboard follows your system’s setting.
Every dialog has one look, the one the Switch workflows and Connect GitHub dialogs had. A dialog opens with its field ready to type in, or with nothing marked.
Inside one workspace, a sign-in to AWS adds an account beside the ones signed in to (the set-up page offers “Another AWS account”; in a terminal, superci login aws --add), for a control plane in one account and a place to move to in another; superci planes create aws --region=… --account=ID names the account. Each control plane is changed with the sign-in of its own account.
A workspace is meant to have one control plane in use. If one has several that each serve a code host, its pages open on the list of them and carry the one shown in their address, and commands name theirs with --plane=ID (or SUPERCI_PLANE=ID); one that names none stops and lists them.
A job that AWS refuses because your account’s limit of running CPUs is in use by your own jobs now waits for one of them to end, as it would on GitHub’s own runners, and starts at the next sweep after. Before, it was tried three times in forty seconds and then failed. When nothing of yours runs there (the limit is below what the job asks, or something else in the account uses it), it still fails after three tries, and now says so plainly: how many CPUs it asked for, and the two limits to raise in Service Quotas, with their links.
The runner that fails a job on GitHub with the reason is asked for as a spot machine and then as an on-demand one, in each of your regions (before: spot only, in the first region). So the reason is delivered even when the spot limit is the reason. Not when on-demand is turned off in your order.
Jobs GitHub never told your control plane of are also looked for in repositories whose last job was up to two weeks ago, five of them at each look (before: only repositories with a job in the last day). The first push after a quiet weekend no longer rests on one event.
Connecting an organization you do not own: the dialog offers a note to copy and send to an owner (GitHub lets only owners create an organization’s App, and shows anyone else a 404). superci github create OWNER --dry-run prints the same note.
Control planes of two teams reached from one computer (two cloud accounts signed in to, one after the other or side by side) can no longer damage each other. superci leave deletes the control plane it lets go of and the ones that serve nothing, and leaves one that serves a code host of its own (before: every control plane it found). A move refuses a target that serves a code host of its own (before: that one’s GitHub App and settings were replaced). Delete refuses such a one as well. And a setting, an update or a delete is refused when SuperCI is signed in to another account than the control plane’s own, saying which (before: it was written into the other account, or nowhere, and reported as done).
--plane=ID is a check: a command stops, with nothing done, when the control plane it would act on is another one. SUPERCI_PLANE given without SUPERCI_KEY does the same, by id or by address. Before, the flag was accepted and ignored, and the variable alone too.
superci planes update ID no longer makes the control plane it updated the one later commands act on.
superci leave --plane=ID --confirm stops one control plane by itself: GitHub and GitLab stop sending it jobs and it is deleted, and the others go on as before. Whatever a leave or a delete leaves behind is named, with the command that removes it later.
A setting that the control plane has not shown twenty seconds after it was written is said as that (before: reported as done).
Each control plane is asked with a key of its own, made from the key kept on your computer and the control plane’s address. Before, one key value sat in every control plane your sign-ins reached, so whoever could read one control plane’s settings held a key the others took. A key from before goes on working until every control plane listed has been handed its own, then it is removed from them. superci logout now removes this computer’s key from every control plane that has it (before: from one).
A sign-in made by another SuperCI process on the same computer (a superci login in a terminal while the dashboard runs, a second dashboard) is taken in by a running dashboard at its next page. Before, the dashboard’s next write put its own older state back and undid that sign-in. superci logout elsewhere signs a running dashboard out too.
Cloudflare runners for a control plane that lives elsewhere go into the one Cloudflare account your sign-in reaches, or the one named (superci runners create cloudflare --account=ID); with several and none named, SuperCI asks which (before: the first one). The Control plane page says a control plane is signed in to only when the sign-in is for its own account.
A second dashboard on the same computer works. With port 8976 taken, superci dashboard and superci login aws use the next free port and say so (before: “port 8976 is in use”). Signing in with AWS, Modal or GitHub comes back to that port (before, AWS’s always came back to 8976, into the other dashboard). Each dashboard keeps its own tab signed in (before, opening one signed the other’s tab out). Only Cloudflare’s browser sign-in still needs port 8976 itself, and says so.