Skip to main content
Automation: SDK, MCP & CI

Check whether your workflows run on TOVIO

The compatibility report, and the ladder it grades against.

Written By Dustin

Last updated About 1 month 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.

ClassWhat it is
nativeA run: step, executed directly as a shell script. If a step has both run: and uses:, the run: is what executes.
shimmedA first-party action TOVIO reimplements natively, backed by a TOVIO primitive instead of fetching the upstream action.
containerA docker://โ€ฆ action. Needs a Docker-in-Docker runner tier.
unsupportedAn 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.

ActionBacked by
actions/checkoutMaterializes the change's tree from the object store โ€” not a github.com clone.
actions/cacheRepo- and run-scoped cache. Advisory: a miss never fails a job.
actions/upload-artifact, actions/download-artifactRun-scoped artifact storage.
actions/setup-node, -python, -java, -goToolchain 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.