Check whether your workflows run on TOVIO

The compatibility report, and the ladder it grades against.

Written By Dustin

Last updated About 3 hours ago

tovio ci check

Reports how every pipeline in your working copy classifies — both .github/workflows/*.yml and every committed config-as-code lockfile — grading each job and step. It is read-only, takes no repository lock, and accepts no flags of its own beyond the global --json and --quiet.

The ladder

Classification fails toward unsupported. It never claims a step is runnable that it cannot prove.

Class	What it is
`native`	A `run:` step, executed directly as a shell script. If a step has both `run:` and `uses:`, the `run:` is what executes.
`shimmed`	A first-party action TOVIO reimplements natively, backed by a TOVIO primitive instead of fetching the upstream action.
`container`	A `docker://…` action. Needs a Docker-in-Docker runner tier.
`unsupported`	An arbitrary marketplace action, a local action, or a step with neither `run:` nor `uses:`. Carries a specific reason.

A whole job is marked not runnable when runs-on names Windows or macOS (only Linux runners are supported) or when the job is a reusable-workflow call.

The shim set

Matching is version-independent and by prefix, so @v4 and @<sha> resolve to the same shim.

Action	Backed by
`actions/checkout`	Materializes the change's tree from the object store — not a github.com clone.
`actions/cache`	Repo- and run-scoped cache. Advisory: a miss never fails a job.
`actions/upload-artifact`, `actions/download-artifact`	Run-scoped artifact storage.
`actions/setup-node`, `-python`, `-java`, `-go`	Toolchain installs into the toolcache, prepending `$GITHUB_PATH`.

A workflow built from run: steps plus these shims runs with no marketplace fetch at all. Because a run: step is a plain shell script, any build tool you already use — make, just, a shell script, anything — works with no special support.

One advisory worth reading

A run: step that calls api.github.com directly is flagged, because GITHUB_TOKEN in a TOVIO job authenticates TOVIO, not GitHub.

The report is machine-readable

tovio ci check --json emits a workflows array. Each entry carries path, kind ("yaml" or "config-as-code"), and then either report plus fully_supported, or an error string in place of the report. fully_supported is true only when all three hold: every job's runner is supported, every step classifies as something other than unsupported, and there are no unsupported triggers. A container step counts as supported — it needs a Docker-in-Docker runner tier, it is not a blocker.

It never lies about finding nothing

An unparseable pipeline is reported and skipped, never fatal. A .lock.json from some other tool is skipped silently. But a genuine TOVIO lockfile that is corrupt is reported, and a tampered one — body edited, address preserved — is caught by verification and reported, never trusted. So ci check cannot falsely claim "no pipelines" over a broken one.

Status

This is the front half of hosted CI: import detection and the compatibility report. The hosted executor itself lands milestone by milestone. Run your own runners today.