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.

How do I integrate GauntletCI with GitLab CI?

Add a job using the mcr.microsoft.com/dotnet/sdk:8.0 image with the rule: if: $CI_PIPELINE_SOURCE == 'merge_request_event'. Install GauntletCI, export PATH, fetch the target branch, generate a diff, and run gauntletci analyze --diff pr.diff.

How do I block an MR merge in GitLab if GauntletCI finds issues?

Set allow_failure: false on the job (the default). GauntletCI exits with code 1 on Block-severity findings, which marks the job as failed and prevents the MR from being merged if a required approval or pipeline rule is configured.

How do I make the GauntletCI job advisory only in GitLab?

Set allow_failure: true on the job. Findings will be reported in the pipeline but will not block the merge.

Does GauntletCI work with GitLab shared runners?

Yes. The job uses the mcr.microsoft.com/dotnet/sdk:8.0 Docker image, which is available on any GitLab runner with Docker executor. No custom runner configuration is needed.

CI/CD

GitLab CI Integration

Add a GauntletCI job to your .gitlab-ci.yml to analyze every merge request diff and block high-risk changes from merging.

Basic setup

Add this job to your .gitlab-ci.yml. It runs only on merge request pipelines using the official Microsoft .NET SDK Docker image:

gauntletci-analysis:
  image: mcr.microsoft.com/dotnet/sdk:8.0
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - export PATH="$PATH:$HOME/.dotnet/tools"
    - dotnet tool install -g GauntletCI
    - git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
    - git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD > pr.diff
    - gauntletci analyze --diff pr.diff --no-banner --ascii
  allow_failure: false

$CI_MERGE_REQUEST_TARGET_BRANCH_NAME is set automatically by GitLab on MR pipelines.
allow_failure: false marks the MR pipeline as failed if findings are detected.
The --ascii flag prevents Unicode box-drawing characters from corrupting the job log.

Advisory mode

To report findings without blocking the merge, set allow_failure: true:

gauntletci-analysis:
  image: mcr.microsoft.com/dotnet/sdk:8.0
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - export PATH="$PATH:$HOME/.dotnet/tools"
    - dotnet tool install -g GauntletCI
    - git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
    - git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD > pr.diff
    - gauntletci analyze --diff pr.diff --no-banner --ascii
  allow_failure: true   # findings reported but MR not blocked

Save findings as a pipeline artifact

Use --output json to write a structured report and upload it as a GitLab artifact:

gauntletci-analysis:
  image: mcr.microsoft.com/dotnet/sdk:8.0
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - export PATH="$PATH:$HOME/.dotnet/tools"
    - dotnet tool install -g GauntletCI
    - git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
    - git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD > pr.diff
    - gauntletci analyze --diff pr.diff --output json --no-banner > gauntletci-report.json
  artifacts:
    paths:
      - gauntletci-report.json
    expire_in: 7 days
  allow_failure: false

The artifact is available under Browse artifacts on the pipeline job page and can be downloaded or used by downstream jobs.

Pipeline mockup

Pipeline #1042MR !18: fix order total calculation

build0:42

test1:14

gauntletci-analysis2 block findings0:08

A failed gauntletci-analysis job blocks the merge button when GitLab is configured with a required pipeline status rule.

Sensitivity configuration

Pass --sensitivity to control which findings are reported. You can also set it via a CI/CD variable so different branches use different levels:

    - gauntletci analyze --diff pr.diff \
        --sensitivity ${GAUNTLETCI_SENSITIVITY:-balanced} \
        --no-banner --ascii

Set GAUNTLETCI_SENSITIVITY as a GitLab CI/CD variable under Settings > CI/CD > Variables. Defaults to balanced if unset.