Shipmoor in CI is the same binary doing the same scan it does on your laptop — installed onto your runner, scoped to the change, exiting with a stable code. No source is uploaded anywhere: the scan happens on your infrastructure, and the only thing handed to GitHub is the SARIF evidence you choose to upload.
The recommended pattern
Three decisions make a good Shipmoor CI gate, regardless of CI provider:
- Scope to the change. Scan the merge-base diff (
--diff origin/main...HEADwithfetch-depth: 0), so PRs are gated on what they introduce, never on legacy findings. See Gating & policy. - Pick the threshold deliberately.
--fail-on highis the sensible default: hallucinated dependencies block, debug output doesn’t. - Emit evidence either way. Write SARIF (and a markdown summary) on every run, and upload it even when the gate fails the job — that’s what populates code scanning.
shipmoor scan --diff origin/main...HEAD \
--sarif --output shipmoor.sarif \
--markdown-summary "$GITHUB_STEP_SUMMARY" \
--fail-on highInstallation on a runner is the same one-liner as anywhere else (curl -fsSL https://dl.shipmoor.dev/install.sh | bash); the free Community scan needs no account or secret in CI.
Handling the exit codes
The contract is four stable codes — and the most common CI mistake is treating 1 as a tooling failure:
| Code | Meaning | CI handling |
|---|---|---|
0 | Clean | Pass |
1 | The gate fired | The gate working. Fail the check; the SARIF/JSON is still complete — upload it. |
2 | Usage/config error | Fix the invocation |
3 | Scan failed | Report as a tooling error |
See Output formats & exit codes for the full contract.
GitHub Actions
Two ready-made options — a copy-paste workflow and a composite action (shipmoor/shipmoor-cli@v0) — are covered in GitHub Actions. Any other CI (GitLab, Buildkite, Jenkins, a bare cron) follows the same pattern: install, scan the diff, act on the exit code, keep the report as an artifact.
Claim Check in CI
On an IC plan, the same CI scan can carry the claim check: pass the task’s intent (--intent, or a .shipmoor/intent.txt your workflow writes) and, if you’ve opted into the gate, a --verdict-policy. Roll it out with --would-block first — see Turning on the gate.
Coming soon — Team. Managed CI gates, PR comments, shared baselines, and team policy are the upcoming Team tier, built on this same local-first core. Everything on this page works today on any plan, including free.
Next
- GitHub Actions — the workflow and the composite action.
- SARIF & code scanning — getting findings into the Security tab.
- Gating & policy — tuning what blocks.