CI & pipelines

Sencai’s CI is Actions-compatible: you write ordinary workflow files in a repository, and Sencai runs them. This page covers where workflow files go, where to watch runs, and how to provision the compute that executes them.

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.

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.

Viewing pipeline runs

CI / Pipelines (/gravity/git/ci) 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 (success, failed, running, cancelled) with the toggle above the table.

Clicking a run opens a side panel with the run’s identifying details and a link to open the full run - including its logs - directly in the underlying Git host. Sencai’s own run list is metadata only; it doesn’t stream or store run logs itself, so use that link when you need to see what a step actually printed.

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. Secrets are write-only after saving - you can replace a value but never read it back through the UI.

CI runners

Workflows need somewhere to run. CI Runners (/gravity/git/runners) is compute you provision specifically for this - distinct from the workflow run viewer above, this page is about the workers that pick jobs up.

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.

What’s next

• Repositories - where workflow files and CI secrets/variables live
• Container registry - where images your pipelines build and push end up
• Connect a cloud provider - the prerequisite for provisioning cloud compute, CI runners included
• Costs - how runner compute shows up in your spend