Vetrix Docs

CI/CD

Everything a repository needs to run pipelines on Vetrix: writing the pipeline file, controlling which jobs fire on which branch, provisioning the runner that executes them, and configuring the scanners and gates that inspect the result. The schema is deliberately narrow and is not GitLab CI or GitHub Actions — most keys copied from either system are rejected at parse time with a named replacement, so start from the authoring pages rather than from an existing file.

Three pairs of filenames look interchangeable and are not. first-pipeline.md is the pipeline tutorial while quickstart.md is the first run for security scanning; authoring-vetrix-pipelines.md is the prose guide to writing the file while pipeline-reference.md is the schema it is written against; and configure.md is the scanner-config wizard while pipeline-configuration.md is the runner environment a job class needs.

Start here

  • Create your first pipeline — The pipeline tutorial: add .ci/pipeline.yml, push it, and check each step against the exact status, badge, and log lines the Pipelines tab should show.
  • 10-minute quickstart — The first run for security scanning rather than pipelines: run the Configure wizard, watch the first scan land, and triage the findings list.

Writing a pipeline file

  • Authoring a pipeline file — The prose authoring guide written against the parser: accepted structure, every rejected GitLab or GitHub key paired with its Vetrix equivalent, and the working idioms for secrets and service containers.
  • Pipeline YAML reference — The schema itself as field tables: required and optional job keys with their defaults, the predefined CI_* variables, artifacts, and allow_failure semantics.
  • Triggers and branch filtering — When a run is created and what each trigger badge means (push, manual, schedule, api), plus how to start a manual run, a retrigger, or an API trigger.

Running jobs

  • Pipeline job configuration — What a job needs from its environment rather than from its YAML: the runner env knobs, and the per-class prerequisites for browser end-to-end, database-integration, and registry-publish jobs.
  • Runners (Docker daemon requirement) — The provisioning contract for a self-hosted worker, starting from the fact that the Docker socket is withheld from job containers until an operator grants it, plus the archive versus git workspace modes.
  • Job dispatch — Why the v1 queue-only dispatcher is the only one left after the cicd_v2 controller was sunset and its code removed, and why an empty runner_hosts table is expected rather than a fault.

Scanning and gates

  • The Configure wizard — The UI generator for .vetrix/tooling.yml — detect, propose, edit, commit — with the two permission grants it checks and the hourly cap on commits.
  • Policy gates — The policy: block's merge and deploy block_on rules, the keys each entry matches on, and the order the instance Rego, per-repo Rego, and YAML layers are evaluated in.

Results and visibility

  • Surfacing pipeline coverage — How to populate the Coverage Report on a pipeline page: write a coverage-summary.json at the workspace root and the runner collects it without an artifacts.paths entry.
  • Deployments feed — The instance-wide deployment-transition feed: the shipped event shape, per-viewer ACL filter, and terminal-event-safe coalescer, and which transport and UI layers are still deferred.

Reference

  • Pricing — States that self-hosted CI/CD is unmetered: no pipeline minutes, runners, jobs, or artifact bytes are counted, and the duration shown on a run is wall-clock only.

Security

  • CI/CD security — The security-review record for the execution surface: the findings index, the manual checklist and its verification tiers, and supply-chain scanner coverage against self-propagating npm worms.