Skip to content
ci-parity

CI setup

Run ci-parity in GitHub Actions: annotations on pull requests, code scanning alerts, or counts for a later step.

flowchart LR
    pr["Pull request"] --> job["Workflow job:<br/>checkout, then<br/>jimmykurian/ci-parity@v0"]
    job -->|"format: github<br/>(default)"| ann["Annotations on the<br/>changed workflow lines"]
    job -->|"format: sarif"| up["upload-sarif"] --> cs["Code scanning alerts,<br/>each linked to its rule page"]
    job -->|"fail-on-error: false"| out["Outputs: errors,<br/>warnings, tolerated"]

Annotations on pull requests

Section titled “Annotations on pull requests”

The action’s default format, github, turns each finding into an annotation on the workflow line that caused it. The job fails when there are errors.

name: ci-parity
on: [pull_request]


jobs:
  ci-parity:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v7
      - uses: jimmykurian/ci-parity@v0

On the pull request, each finding appears on its line in Files changed:

A pull request’s Files changed tab. Under line 21, run: golangci-lint run ./…, a Self-check annotation reads P001 inline-tool: step “Lint Go” in job “checks” runs ‘golangci-lint run ./…’ directly; already available as ‘task lint’. Below it, a code scanning alert from github-advanced-security repeats the finding.

Each annotation is one line of workflow commands in the job log:

::error file=.github/workflows/ci.yml,line=7,col=14,title=P001 inline-tool::step "Test" in job "web" runs 'pnpm test' directly; already available as 'task test'

Paths are relative to working-directory, so annotations line up only when it’s the root of the checked-out repository (the default).

Code scanning

Section titled “Code scanning”

With format: sarif, the action writes a SARIF log and gives its path as the sarif-file output. Upload it, and the findings appear in the repository’s Security tab as code scanning alerts, each linked to its rule’s page here.

jobs:
  ci-parity:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v7
      - uses: jimmykurian/ci-parity@v0
        id: parity
        with:
          format: sarif
          fail-on-error: false
      - uses: github/codeql-action/upload-sarif@v4
        with:
          sarif_file: ${{ steps.parity.outputs.sarif-file }}
          category: ci-parity

On a pull request, the code scanning check lists the new alerts, each on its line:

The code scanning check for ci-parity on a pull request: 4 new alerts including 4 errors. Annotations show a P004 on line 1 of .github/workflows/demo.yml, and P001 findings on lines 21 and 23, each with the task already available.

  • Errors are error alerts, warnings warning, and tolerated findings note.
  • An allowed finding is uploaded as suppressed in source, with its reason, so code scanning shows it as dismissed.
  • Each alert carries a fingerprint built from the rule, file, job, step and command, so moving lines doesn’t open a new one.
  • With fail-on-error: false, the job succeeds and code scanning reports the findings; leave it true to also fail the job.

Code scanning is free for public repositories; private ones need GitHub Advanced Security.

Counts for later steps

Section titled “Counts for later steps”

With fail-on-error: false, the step always succeeds and its outputs carry the counts:

      - uses: jimmykurian/ci-parity@v0
        id: parity
        with:
          fail-on-error: false
      - if: steps.parity.outputs.errors != '0'
        run: echo "::warning::${{ steps.parity.outputs.errors }} ci-parity errors"

The outputs are errors, warnings, tolerated and sarif-file; the action reference has every input and output. For your own tooling, ci-parity check --format json prints a document whose shape changes only with its version; see the output formats.

A baseline in CI

Section titled “A baseline in CI”

Commit .ci-parity-baseline.json, and the action uses it like check does: tolerated findings pass, and a rise fails with P004. Set strict: true to ignore the baseline, for example in a scheduled job that tracks what’s left. See Adopting with a baseline.

See also

Section titled “See also”

Last reviewed: 2026-10-28