Rigor CI Setup

Rigor CI Setup

Wire Rigor into a project's CI so type diagnostics appear inline on the pull / merge request, not just in the job log. This skill is the workflow — detect the platform, choose the surface, apply the matching template, pin, gate, verify. It does not copy the CI YAML inline: the authoritative, version-matched templates live in the manual's CI chapter (rigor docs ci) and as ready-to-copy files, so this skill cannot drift out of date as --format surfaces and action versions move.

This is for users running Rigor on their own project with the published rigor executable — Rigor is a tool, not a library, so it is not added to the project's Gemfile.

First: load the version-current copy

Follow the copy that ships with the installed Rigor, not any vendored or frozen copy of this file. Two version-matched sources, both offline once Rigor is installed:

rigor skill --full rigor-ci-setup   # this skill's current workflow, in one call
rigor docs ci                       # the manual's CI chapter — the actual templates

If you already loaded this skill via rigor skill you have the current copy — just proceed. If rigor is not on PATH, this task needs it: run rigor-next-steps to install Rigor first, then come back.

The one hard rule: Rigor gets its own job

Rigor runs on Ruby 4.0. ruby/setup-ruby sets the job's active Ruby, so a job that provisions the project's test Ruby (often 3.x, or a matrix) cannot also provision Rigor's 4.0 — the second setup-ruby clobbers the first. Always give Rigor a separate job (better: a separate workflow file, for its own triggers, concurrency, and status badge). Every template in rigor docs ci does this.

Phase 0 — Detect the project's CI platform

Inspect the repository first; do not ask what you can detect. Look for these markers from the project root and let them drive the platform choice:

Concretely:

• List .github/workflows/*.yml and .gitlab-ci.yml. If .github/workflows/rigor.yml already exists, read it — this is an update, not a fresh add: preserve the user's triggers / pinning and only change the format / steps that are wrong or missing. The same applies to an existing rigor job inside .gitlab-ci.yml.
• Check for an existing pin: .github/rigor/Gemfile (+ lockfile) means the project already pins Rigor — keep it (Phase 3).
• Check for .rigor-baseline.yml — if present, the project is in baseline adoption mode, which changes the gate advice (Phase 4).
• Grep existing CI files for reviewdog — if already used, prefer the reviewdog surface for consistency.

Routing: exactly one platform marker → use it, state what you found, and proceed. Multiple (e.g. both .github/workflows/ and .gitlab-ci.yml) → tell the user both were found and ask which to wire (or do both). None → ask.

Phase 1 — Pick the surface (what the reviewer should see)

All --format surfaces are pure renderings of the same diagnostics; the exit code is unchanged (0 clean, 1 on errors), so the job still gates. The full format→platform table and severity mapping are in rigor docs ci; this is the decision:

• GitHub → lead with github (annotations). It works on every repository with zero setup — no upload, no permissions, no paid features. In fact Rigor auto-detects GitHub Actions / TeamCity and emits native annotations even without --format, so a plain rigor check already annotates the PR (--no-ci-detect turns that off). Only upgrade when there is a concrete reason:
  • sarif (Security tab, deduped/persistent alerts) — only when code scanning is available: a public repo (free) or a private repo with GitHub Advanced Security. Without it upload-sarif fails. If you cannot tell, do not default to SARIF — use github and offer SARIF to a public-repo / GHAS user.
  • reviewdog when the team wants threaded review comments filtered to changed lines (works on private repos; needs a token — Phase 2).
  • Annotation caveat: the run UI caps annotations per type, so on a first adoption of a large codebase prefer the baseline gate (Phase 4) or SARIF/reviewdog, which page through everything.
• GitLab → gitlab (the MR Code Quality widget) or reviewdog.
• Any test-report CI (CircleCI, Jenkins, …) → junit.