How does GauntletCI compare to SonarQube?

SonarQube analyzes the entire codebase on a schedule and requires a server, account, and network access. GauntletCI analyzes only the lines that changed in the current diff, runs entirely on the developer's machine in under one second, requires no account or cloud connection, and installs as a pre-commit hook. SonarQube is a full codebase quality platform; GauntletCI is a focused change-risk detector that runs before a commit is ever created.

How does GauntletCI compare to Semgrep?

Semgrep is a pattern-matching engine that scans files or the full codebase. GauntletCI scopes every rule to the changed diff, meaning it only flags risks introduced by the current change, not pre-existing issues in unchanged files. GauntletCI also includes incident correlation, local LLM enrichment, and baseline delta mode, which Semgrep does not offer. GauntletCI's free tier includes all rules with no account required.

How does GauntletCI compare to Snyk?

Snyk is primarily a dependency and container vulnerability scanner that requires cloud connectivity and a Snyk account. GauntletCI detects behavioral, structural, and security risks in first-party code changes, not dependency vulnerabilities, and runs 100% locally with no data transmitted. GauntletCI is suitable for air-gapped environments and organizations with strict data residency requirements; Snyk is not.

How does GauntletCI compare to CodeQL / GitHub Advanced Security?

CodeQL performs deep semantic analysis of the full codebase and requires compilation and significant compute time, typically minutes per run. GauntletCI analyzes only the changed diff in under one second with no compilation step, making it suitable as a pre-commit hook in the developer's local workflow. CodeQL is better for periodic deep security audits; GauntletCI is better for fast, continuous feedback on every commit.

How does GauntletCI compare to Code Climate?

Code Climate is a SaaS platform that analyzes full repositories for maintainability and test coverage trends over time. It requires uploading code to a cloud service. GauntletCI is fully local, diff-scoped, and focused on change risk rather than codebase health metrics. GauntletCI does not require a cloud account, never transmits code, and produces results in under one second, making it a complement to, not a replacement for, Code Climate's longitudinal reporting.

Does GauntletCI work in air-gapped or offline environments?

Yes. GauntletCI runs entirely on the local machine. No diff, finding, file path, or telemetry is transmitted. The optional local LLM enrichment feature (--with-llm) uses a locally hosted Ollama model, with no network call. This makes GauntletCI suitable for classified, regulated, or air-gapped environments where cloud-based analysis tools are prohibited.

What is baseline delta mode and do other tools offer it?

Baseline delta mode (gauntletci baseline capture) snapshots all current findings and suppresses them from future runs. Only net-new findings (risks introduced after the baseline) are reported. This eliminates alert fatigue from pre-existing issues in legacy codebases. SonarQube offers a similar 'new code' concept but requires server setup. Semgrep, Snyk, CodeQL, and Code Climate do not offer equivalent pre-commit baseline suppression.

Does the GauntletCI GitHub Action need a token to post inline comments?

Yes. Set pull-requests: write in the permissions block of your calling workflow. The action uses the default GITHUB_TOKEN - no personal access token is required.

How do I prevent the GauntletCI action from failing the build?

Set fail-on-findings: 'false'. The action will still run and report findings but will exit with code 0 regardless of results.

What does the findings-count output contain?

findings-count is a string containing the number of findings GauntletCI produced. It counts lines in the output that match a GCI rule ID pattern. Use it in subsequent steps to conditionally post Slack alerts or upload artifacts.

Can I pin to a specific GauntletCI tool version?

Yes. Set gauntletci-version to the exact NuGet version you want, such as '2.1.0'. The default is the latest published version.

Extensions - GitHub Action

GitHub Action

The GauntletCI GitHub Action analyzes every pull request against your repository rules and optionally posts findings as inline review comments - without any runner setup or credentials beyond the default GITHUB_TOKEN.

Quickstart

Add this workflow to .github/workflows/gauntletci.yml in your repository. No additional configuration is required.

name: GauntletCI

on:
  pull_request:
    branches: [main]

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

      - uses: EricCogen/GauntletCI@v2.1.1

This runs with all defaults: balanced sensitivity, findings fail the check, no inline comments. To post findings as inline PR review comments, add pull-requests: write and set inline-comments: 'true'.

Full example with inline comments

name: GauntletCI

on:
  pull_request:
    branches: [main]

permissions:
  pull-requests: write   # required for inline-comments: 'true'

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

      - uses: EricCogen/GauntletCI@v2.1.1
        id: gauntlet
        with:
          sensitivity: 'balanced'
          inline-comments: 'true'
          fail-on-findings: 'true'

      - name: Upload findings artifact
        if: always()
        run: |
          echo "Findings count: ${{ steps.gauntlet.outputs.findings-count }}"

How inline comments look

When inline-comments: 'true' is set, GauntletCI posts each finding as a GitHub review comment on the exact diff line it originated from.

Pull Request - Files Changed - OrderService.cs

+ await _repository.SaveAsync(order);

gauntletci-bot commented

[Block] GCI0001 - Behavior Change Without Test Coverage

Summary: SaveAsync was modified but no test file covering OrderService was updated.

Suggested action: Add or update a test that exercises the new behavior before merging.

Inputs

Input	Default	Description
sensitivity	"balanced"	strict \| balanced \| permissive. Controls which confidence levels trigger findings.
fail-on-findings	"true"	Exit with code 1 when any findings are produced, failing the GitHub check.
inline-comments	"false"	Post findings as inline PR review comments. Requires pull-requests: write.
no-llm	"true"	Disable LLM enrichment. Recommended for CI - keeps the step deterministic and fast.
ascii	"true"	Use ASCII-only output. Recommended for CI logs - avoids encoding issues.
commit	""	Commit SHA to analyze. Defaults to the PR head commit (github.event.pull_request.head.sha).
dotnet-version	"8.0.x"	The .NET SDK version to install on the runner.
gauntletci-version	"2.1.1"	The GauntletCI NuGet tool version to install.

Outputs

Output	Description
findings-count	Number of findings detected. Reference as `${{ steps.<id>.outputs.findings-count }}` in downstream steps.

Permissions required

Feature	Permission needed
Basic analysis (no comments)	None - uses default runner permissions
GitHub Checks annotations	checks: write (automatic on pull_request)
Inline PR review comments	pull-requests: write (must be set explicitly)

Advisory-only mode

To run GauntletCI as an informational check that never blocks merges, set fail-on-findings: 'false'. Findings still appear in the job log and as inline comments (if enabled), but the check always passes.

- uses: EricCogen/GauntletCI@v2.1.1
  with:
    fail-on-findings: 'false'
    inline-comments: 'true'
    sensitivity: 'permissive'