GitHub Actions

Shipmoor runs in CI the same way it runs locally: it installs a binary, scans the change, and exits with a stable code. No source is uploaded; the scan happens on your runner, and only SARIF is handed to GitHub code scanning.

Option 1: the workflow

Drop this in .github/workflows/shipmoor.yml:

name: Shipmoor

on:
  pull_request:
  push:
    branches: [main]

jobs:
  shipmoor:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - name: Install Shipmoor CLI
        run: curl -fsSL https://dl.shipmoor.dev/install.sh | bash
      - name: Add Shipmoor to PATH
        run: echo "$HOME/.shipmoor/bin" >> "$GITHUB_PATH"
      - name: Run Shipmoor
        run: |
          shipmoor scan --changed \
            --sarif --output shipmoor.sarif \
            --markdown-summary "$GITHUB_STEP_SUMMARY" \
            --fail-on high
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: shipmoor.sarif

The install step drops the shipmoor binary in $HOME/.shipmoor/bin; the next step adds that directory to $GITHUB_PATH so later steps can call shipmoor directly. --markdown-summary "$GITHUB_STEP_SUMMARY" writes a readable summary into the job page; --fail-on high makes the job fail when a high-or-above finding lands.

contents: read lets the job check out your code; security-events: write lets upload-sarif publish findings to GitHub code scanning. Both are required for the SARIF upload to appear in the Security tab.

Option 2: the composite action

For a shorter step, use the bundled composite action. It installs from the same canonical host (https://dl.shipmoor.dev/install.sh) and adds $HOME/.shipmoor/bin to the runner PATH for you:

      - uses: shipmoor/shipmoor-cli@v0
        with:
          changed: "true"
          fail-on: high
          sarif-output: shipmoor.sarif

The job still needs the same permissions block and a github/codeql-action/upload-sarif@v3 step to publish the SARIF; the action runs the scan and writes the file, but does not upload it.

Inputs:

When changed is true, the action runs shipmoor scan --changed; otherwise it scans scan-path. Either way it passes --sarif, --output <sarif-output>, and --fail-on <fail-on>.

Exit codes in CI

A gate firing is reported as exit code 1; that’s the gate working, not a tooling error. The JSON/SARIF is still produced. Reserve failure handling for 2 (usage) and 3 (scan failed). See SARIF & code scanning for the full contract.

Server-side CI gates and PR comments (the Team tier) are in preview and build on this same local-first core. Today, the workflow above gives you a blocking gate and code-scanning evidence on any plan.

Next

• CI overview: where the gate fits and what each tier adds.
• SARIF & code scanning: the SARIF contract and the Security-tab view.