Getting started

Install ci-parity, run it on a repository, and read what it reports.

A terminal session: ci-parity check reports three inline tools, each already available as a task; ci-parity fix rewrites the three steps; ci-parity check then reports 0 errors.

Install

GitHub Action

- uses: actions/checkout@v7
- uses: jimmykurian/ci-parity@v0

@v0 follows the latest v0.x release. To pin, use a release tag (@v0.6.0) or, better, its full commit SHA with the tag as a comment. The action downloads that release’s binary for the runner, verifies it against checksums.txt, and runs ci-parity check. Its inputs and outputs are in the GitHub Action reference, and CI setup shows annotations and code scanning.

Release binaries

Each release has archives for linux, darwin and windows on amd64 and arm64, and a checksums.txt:

VERSION=0.8.3 # x-release-please-version
gh release download "v$VERSION" --repo jimmykurian/ci-parity \
  --pattern "ci-parity_${VERSION}_linux_amd64.tar.gz" --pattern checksums.txt
sha256sum --ignore-missing -c checksums.txt
tar -xzf "ci-parity_${VERSION}_linux_amd64.tar.gz"
./ci-parity version

go install

go install github.com/jimmykurian/ci-parity/cmd/ci-parity@latest

A go install build reports its version as dev; the release binaries carry the version, commit and date.

mise

mise installs the release archive for your OS and architecture from GitHub Releases:

mise use github:jimmykurian/ci-parity@0.8.3 # x-release-please-version

Or pin it in mise.toml with the repository’s other tools:

[tools]
"github:jimmykurian/ci-parity" = "0.8.3" # x-release-please-version

pre-commit

With pre-commit, add the hook to .pre-commit-config.yaml:

repos:
  - repo: https://github.com/jimmykurian/ci-parity
    rev: v0.8.3 # x-release-please-version
    hooks:
      - id: ci-parity

pre-commit builds ci-parity from that tag, installing Go if needed, and runs ci-parity check on the whole repository when a commit changes a workflow, an action, the config, the baseline or the runner’s files. If your config reads files from other paths, add always_run: true under id: ci-parity.

With lefthook and ci-parity installed (through mise, say), add a command to lefthook.yml:

pre-commit:
  commands:
    ci-parity:
      run: ci-parity check

First run

A workflow that calls pnpm directly, next to a Taskfile that already wraps those commands:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Install
        run: pnpm install --frozen-lockfile
      - name: Test
        run: pnpm test
      - name: Lint
        run: task lint

version: "3"

tasks:
  install:
    cmds:
      - pnpm install --frozen-lockfile
  test:
    cmds:
      - pnpm test

$ ci-parity check
.github/workflows/ci.yml
  9:14    P001 inline-tool   step "Install" in job "test" runs 'pnpm install --frozen-lockfile' directly; already available as 'task install'
  11:14   P001 inline-tool   step "Test" in job "test" runs 'pnpm test' directly; already available as 'task test'
  13:19   P002 unknown-task  'task lint' is not defined in Taskfile.yml (closest: test)

3 errors, 0 warnings, 0 tolerated, 0 allowed

Each line is a position, a rule and a message. Here there are two inline tools with the task that already runs them, and one unknown task. After calling the tasks instead (and installing task in a uses: step), it’s clean:

    steps:
      - uses: actions/checkout@v7
      - uses: go-task/setup-task@v2
      - name: Install
        run: task install
      - name: Test
        run: task test

$ ci-parity check
0 errors, 0 warnings, 0 tolerated, 0 allowed

ci-parity fix makes changes like these for you; see Fixing findings.

Next steps

A repository with many inline steps can start from a baseline and shrink it: Adopting with a baseline.
Make, just or mise instead of Taskfile: Configuring and the recipes.
Running it in CI, with annotations or code scanning: CI setup.