CI integration

Pullminder ships a dedicated ci command that auto-detects your CI environment, resolves the correct base branch, and produces output in formats that CI systems understand (SARIF, JUnit, GitHub annotations). You can also use the standard check command if you need more control.

GitHub Actions

Basic workflow

The simplest GitHub Actions setup runs pullminder ci on every pull request:

.github/workflows/pullminder.yml

name: Pullminder

on:
  pull_request:

permissions:
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Pullminder
        run: curl -fsSL https://get.pullminder.com | sh

      - name: Run analysis
        run: pullminder ci --fail-on high
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Setting fetch-depth: 0 ensures the full Git history is available so Pullminder can compute the diff against the base branch.

With SARIF upload to GitHub Code Scanning

Upload SARIF results to GitHub Code Scanning so findings appear in the Security tab and as inline annotations on pull requests:

name: Pullminder

on:
  pull_request:

permissions:
  contents: read
  security-events: write

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Pullminder
        run: curl -fsSL https://get.pullminder.com | sh

      - name: Run analysis
        run: pullminder ci --sarif > pullminder.sarif
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: pullminder.sarif
          category: pullminder

The if: always() on the upload step ensures results are uploaded even when Pullminder exits with a non-zero code due to findings.

With GitHub annotations

Use --github-annotations to emit ::warning and ::error workflow commands. Findings appear as inline annotations directly on the Files Changed tab of the pull request:

name: Pullminder

on:
  pull_request:

permissions:
  contents: read

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Pullminder
        run: curl -fsSL https://get.pullminder.com | sh

      - name: Run analysis
        run: pullminder ci --github-annotations --fail-on critical
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

You can combine --github-annotations with --sarif or --junit to produce multiple output formats in a single run.

Using the official GitHub Action

For registry validation in CI, use the pullminder/action@v1 action:

name: Validate registry

on:
  pull_request:
    paths:
      - 'packs/**'
      - 'registry.yml'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pullminder/action@v1
        with:
          command: registry validate --strict

The action handles installation and caching automatically.

---

GitLab CI

Basic pipeline

.gitlab-ci.yml

pullminder:
  stage: test
  image: ubuntu:latest
  before_script:
    - apt-get update && apt-get install -y curl git
    - curl -fsSL https://get.pullminder.com | sh
  script:
    - pullminder ci --fail-on high
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

With JUnit artifacts

GitLab can display test results from JUnit XML reports. Use --junit to generate a report and declare it as an artifact:

pullminder:
  stage: test
  image: ubuntu:latest
  before_script:
    - apt-get update && apt-get install -y curl git
    - curl -fsSL https://get.pullminder.com | sh
  script:
    - pullminder ci --junit > pullminder-report.xml
  artifacts:
    when: always
    reports:
      junit: pullminder-report.xml
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Setting when: always on the artifact ensures the report is uploaded even when the pipeline fails due to findings.

---

Generic CI (npx)

For any CI system with Node.js available, run Pullminder via npx without a separate install step:

npx @pullminder/cli ci --fail-on high

Pin the version in your pipeline to avoid surprises:

npx @pullminder/cli@1.2.0 ci --fail-on high

This works in CircleCI, Jenkins, Bitbucket Pipelines, Travis CI, Azure DevOps, and any environment where npm is available.

CircleCI example

.circleci/config.yml

version: 2.1

jobs:
  pullminder:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - run:
          name: Run Pullminder
          command: npx @pullminder/cli ci --fail-on high

workflows:
  pr-check:
    jobs:
      - pullminder

Jenkins example

// Jenkinsfile
pipeline {
    agent { docker { image 'node:20' } }
    stages {
        stage('Pullminder') {
            steps {
                sh 'npx @pullminder/cli ci --fail-on high --junit > pullminder-report.xml'
                junit 'pullminder-report.xml'
            }
        }
    }
}

Bitbucket Pipelines example

bitbucket-pipelines.yml

pipelines:
  pull-requests:
    '**':
      - step:
          name: Pullminder
          image: node:20
          script:
            - npx @pullminder/cli ci --fail-on high

---

Severity levels and --fail-on

The --fail-on flag controls which severity levels cause a non-zero exit code. Findings below the threshold are still reported but do not fail the build.

Value	Fails on
critical	Critical findings only.
high	High and critical findings.
medium	Medium, high, and critical findings.
low	Any finding of any severity (equivalent to --strict).

If --fail-on is not set and --strict is not passed, pullminder ci exits 0 as long as analysis completes, regardless of findings.

Choosing a threshold

• --fail-on critical — Recommended starting point. Blocks merges only for the most serious issues (exposed secrets, SQL injection, etc.) while your team gets accustomed to the tool.
• --fail-on high — Good default for most teams. Catches security vulnerabilities and high-risk patterns without generating excessive noise.
• --fail-on medium — Stricter. Use this once your team has addressed the backlog of existing findings and wants to enforce broader code quality standards.
• --fail-on low — Maximum strictness. Every finding blocks the build. Best suited for security-critical repositories.

---

Exit codes

Code	Meaning
0	Analysis completed. No findings at or above the configured severity threshold.
1	Findings at or above the threshold were found, or a critical error occurred.
2	Warnings were reported but no findings above the threshold.

---

Environment variables

Pullminder CI commands respect the following environment variables:

Variable	Description
GITHUB_TOKEN / GH_TOKEN	GitHub personal access token or ${{ secrets.GITHUB_TOKEN }} in Actions. Required for platform commands (diff, score, brief).
PULLMINDER_API_HOST	Override the default API host for self-hosted deployments.
NO_COLOR	Disable colored output when set to any value.

---

Next steps

• Command reference — full flag reference for ci, check, and all other commands.
• Installation — install the CLI locally or in Docker images.