CI & pipelines

Sencai’s CI is Actions-compatible: you write ordinary workflow files in a repository, and Sencai runs them. Every job runs on a hosted runner that exists for that one job and is removed when it ends, or on a runner you provisioned yourself. This page covers where workflow files go, the CI / Pipelines page, and runners of your own. How hosted runners work, what limits apply and what they cannot reach is on Hosted runners.

Defining a workflow

Workflow files live in your repository, checked in like any other file. Sencai looks in two directories, in this priority order:

1. .sencai/workflows/
2. .github/workflows/

The filename inside the directory can be anything (ci.yml, build-and-test.yml, and so on) - a push that touches a matching file triggers a run. If you’re migrating an existing GitHub Actions setup, .github/workflows/ is picked up as-is; no rewrite is required to get a first run working.

Choose where a job runs with runs-on. Hosted runners answer to ubuntu-latest, ubuntu-24.04 and ubuntu-22.04; see Hosted runners.

Caution

Mirrored repositories don’t trigger runs. A mirror syncs by pulling, not pushing, so no push event fires on sync - trigger a workflow manually or use a schedule trigger inside the workflow file itself if you need CI on a mirrored repository.

The CI / Pipelines page

CI / Pipelines (/gravity/git/ci) has five tabs. The address keeps the tab you are on, so a link to Queue opens on Queue.

Tab	Shows	Needs
Runs	Recent workflow runs across every repository in the active organization, with the log of a run	Read on repositories
Queue	Jobs waiting for a hosted runner or running on one, with the state of each in words, and Stop	Read CI (git.ci:read)
Hosted runners	The history of hosted runners started for your organization, one row per runner	Read CI
Minutes	The CI minutes used this month, how many are included, and the minutes of each job	Read CI for the minutes used; billing access for the included minutes and the overage cap, Manage billing (billing:manage) to change the cap
Settings	Whether hosted runners are used, the limits, and whether CI jobs may push images	Read CI to see, Manage CI (git.ci:manage) to change

If you lack the permission for a tab, the tab says which permission it needs instead of showing nothing. Hosted runners describes the last four tabs and the permissions in full.

Runs

The Runs tab lists recent workflow runs across every repository in the active organization: status, workflow name, repository, trigger event, ref, duration, and when it started. Filter by status (All, Success, Failed, Running and Cancelled) with the toggle above the table.

Click a run to open its log in a side panel. Reload the log fetches it again while the job is still running. Sencai reads the log from the Git host when you open it and keeps no copy; a log longer than 20 MB is cut and says so at its end. The panel also links to the run on the Git host itself.

If the list cannot be read, the tab shows an error with a retry rather than an empty table, so an empty table means there are no runs.

Secrets available to a pipeline

A workflow reads secrets and variables the same way Actions workflows normally do (secrets.NAME / vars.NAME). What’s available is configured per repository, not per organization: open a repository’s Settings → Secrets & Variables tab (see Repositories) to add or remove them (this needs the Admin role). Secrets are write-only after saving - you can replace a value but never read it back through the UI.

A hosted runner only ever receives jobs, and therefore secrets, of your own organization.

Caution

To push images to your organization’s registry from a workflow, do not store a registry credential in these secrets. Use the credential a hosted job can request for itself: Push images from CI.

Your own runners

Hosted runners are the default. If you want a runner that stays up, that can reach your private network, or that has more capacity than a hosted runner, provision one yourself. CI Runners (/gravity/git/runners) is compute you provision specifically for this - distinct from the workflow run viewer above, this page is about workers that you keep.

A job is offered to your own runner first when its labels match: Sencai waits a short while (20 seconds by default) before it starts a hosted runner for the job, so a free runner of yours takes it. The Queue tab shows Waiting (your runner first) during that wait. If only a runner of yours can take the job, the state is Waiting (your runner) and no hosted runner is started for it.

New runner asks for:

• Name (optional).
• Provider - Hetzner Cloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, or Linode.
• Region (optional) - leave blank for the provider’s default.
• Size - Small (2 vCPU / 2–4 GB, light jobs and linting), Medium (2–4 vCPU / 4–8 GB, typical build/test), or Large (4 vCPU / 8+ GB, heavy builds and image builds).
• Stop overnight - an optional working-hours schedule: active days, a start and stop time, and an IANA timezone (for example America/New_York). Outside that window the runner’s compute powers down automatically; leave it off to keep the runner always on.

The cost shown at creation time is an estimate - your provider’s list price plus Sencai’s management margin - not a bill. The actual charge is computed once the underlying compute reports its real, provider-billed cost, and appears on the runner’s card afterward.

Runner status

A runner’s status tracks where it is in its lifecycle:

Status	Meaning
Provisioning	The cloud compute is being created.
VM up - bootstrap not attempted	The compute exists, but the platform couldn’t hand it a bootstrap script yet - it cannot pick up jobs in this state.
Awaiting runner registration	The compute is up and was given a registration token at boot, but there’s no confirmation yet that it registered - it may not be able to run a job.
Failed	Provisioning failed.
Terminating / Terminated	Being torn down, or already gone.

No status here confirms that a runner is ready to accept jobs, and the list shows green only once a runner is Terminated - that is, torn down. If a runner has sat in one of the “awaiting” states for a long time, deleting and recreating it is a reasonable next step.

Schedule on a runner’s card reopens the working-hours editor at any time. Delete permanently destroys the underlying compute and stops billing for it - this can’t be undone.

Runners of your own are separate from the hosted runners on the Hosted runners tab. The card for your own runners links to the hosted tabs.

What’s next

• Hosted runners - isolation, limits, queue states and what changed from shared build capacity
• Push images from CI - build and push to your registry with a credential that lasts one job
• Repositories - where workflow files and CI secrets/variables live
• Container registry - where pushed images end up, and how they are scanned and signed
• Connect a cloud provider - the prerequisite for provisioning cloud compute, runners of your own included
• Costs - how runner compute shows up in your spend