Run Emendant in GitHub Actions
Emendant exits with a status that CI can read. A workflow can fail on findings and still tell a finding apart from a scan that could not finish.
Exit codes
0: the scan completed and found nothing.1: the scan completed and reported findings.2: the scan could not complete.
A minimal step
- name: Scan for breaking API changes
run: npx --yes emendant scan --no-color
This fails the job when Emendant finds affected code. That is usually the right default for a required check.
To pin the tool, use npx --yes emendant@0.1.3. Coverage still grows under a pinned version, because the feed arrives as signed snapshots and not with the package.
Upload a SARIF report
--sarif prints one SARIF 2.1.0 log for code-scanning tools.
npx --yes emendant@0.1.3 scan --sarif > emendant.sarif
The command still exits 1 when it finds something. Save the exit status before an upload step so that a finding is not read as an interrupted scan.
Keep a JSON report and still fail on findings
- name: Run Emendant
id: emendant
shell: bash
run: |
set +e
npx --yes emendant scan --json > emendant-report.json
status=$?
set -e
echo "status=$status" >> "$GITHUB_OUTPUT"
if [ "$status" -eq 2 ]; then
exit 2
fi
- name: Upload Emendant report
if: always()
uses: actions/upload-artifact@v4
with:
name: emendant-report
path: emendant-report.json
- name: Fail on findings
if: steps.emendant.outputs.status == '1'
run: exit 1
Keep local and CI scans the same
Commit emendant.json so every scan uses the same package, severity and ignore rules. Use flags only for a deliberate one-off change.
Coverage warnings print by default and appear in the JSON. Do not discard them. A clean count with a coverage warning means part of the repository could not be checked.
Coverage. Emendant reports the changes in its feed. A clean scan does not show that an upgrade is complete. See supported projects and known limitations.
The full guide is Use Emendant in CI.