Runs from a computer

Run a workflow’s jobs on your SuperCI machines without pushing. You, or a coding agent, see whether CI would pass before anything leaves your computer.

superci runs create --workflow=.github/workflows/ci.yml
superci runs create --workflow=.github/workflows/ci.yml --job=test   # that job and those it needs

The command waits for the run and prints its jobs’ lines. It fails when the run does.

What goes along

The working tree as it is on your computer: what git tracks, and the new files it does not ignore. An ignored .env stays behind. Nothing is pushed.

It goes through your control plane, so there is no new resource or permission in your cloud. It is kept there only until the run’s jobs have fetched it.

How it runs

As GitHub runs it. GitHub’s own runner runs the steps: actions, service containers, expressions, step outputs.

• Each combination of a matrix is a job of its own, on the machine its runs-on says.
• A job starts once the jobs it needs have ended, and runs if its if holds (by default, if they all succeeded). It knows their results and outputs.
• Jobs use the cache as CI’s do: they read their branch’s and the default branch’s caches, and write a scope of their own, so a run from a computer never changes what CI finds.
• upload-artifact in one job and download-artifact in the next work as on GitHub. Artifacts are kept for a day.

Getting artifacts back

What its jobs kept with upload-artifact can be fetched to your computer:

superci artifacts list --run=ID                 # each artifact's name and size
superci artifacts retrieve coverage --run=ID    # unpacked into ./coverage, as download-artifact would
superci artifacts retrieve coverage --run=ID --out=build/coverage

The run’s id is printed when it starts, and is in superci runs list. A run of GitHub’s keeps its artifacts at GitHub: gh run download fetches those.

What GitHub would give it

Give it on the command line instead:

superci runs create --workflow=.github/workflows/ci.yml \
  --secret=DATABASE_URL=postgres://… --var=REGION=eu \
  --event=pull_request

• --secret is hidden in the job’s lines as GitHub hides secrets, and not kept once the job has ended.
• --event=pull_request when the workflow does something else for one; push unless given.
• There is no GITHUB_TOKEN and no OIDC.

Following it

Its jobs are listed with the others (superci jobs list, Runs), with their machines and their cost. A run from a computer has no page at GitHub, so its page in the dashboard shows how each job stands and its log.

A key for coding agents

An agent on your own computer can use SuperCI’s sign-ins as they are. For one elsewhere, or one you want to keep from changing anything, give it a key:

superci keys create agent --runs
SUPERCI_PLANE=https://… SUPERCI_KEY=superci_… superci runs create --workflow=.github/workflows/ci.yml

The key reads, starts runs from a computer and fetches their artifacts, and changes nothing else. It has no limits of its own: its jobs keep to your control plane’s, as every job does, the largest machine and what may be spent in a month and a day (superci limits update --max-cpu=64 --daily-usd=50).

Not yet

A call of another workflow, and a matrix made by an expression. actions/checkout puts the working tree in place as one commit; another repository is not checked out.