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 install the GauntletCI Azure DevOps extension?

Search for 'GauntletCI' in the Azure DevOps Marketplace and click Get. You can install it organization-wide or for a specific project. Once installed, the GauntletCI Analyze task appears in the task library.

Does the GauntletCI ADO task need .NET installed on the agent?

Yes. The task installs GauntletCI via dotnet tool install -g GauntletCI, so .NET 8 must be available on the agent. Microsoft-hosted ubuntu-latest and windows-latest agents include .NET 8.

What does failOnBlock do in the Azure Pipelines task?

When failOnBlock is true (default), the task sets its result to Failed when one or more Block-severity findings are produced. The pipeline step fails, which blocks PR completion if the branch policy requires a passing build.

How do GauntletCI annotations appear in Azure Pipelines?

Block findings emit ##vso[task.logissue type=error] commands. Warn findings emit ##vso[task.logissue type=warning] commands. These appear as inline error and warning annotations in the pipeline run summary and build log.

Extensions - Azure DevOps

Azure DevOps Task

The GauntletCI Azure Pipelines task installs the CLI, analyzes the current commit, and emits inline annotations in the pipeline run summary - the same red error and yellow warning markers you see from build tasks and test runners.

Install the extension

1.Go to the Azure DevOps Marketplace
2.Search for "GauntletCI"
3.Click Get and choose your organization
4.Confirm the installation - no restart required

Once installed, the GauntletCI@0 task is available in the YAML task library and in the Classic editor task picker.

YAML pipeline

Add this to a new pipeline file in your repository. The pipeline runs on every pull request targeting main.

trigger: none
pr:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-latest

steps:
  - task: UseDotNet@2
    inputs:
      version: '8.0.x'

  - task: GauntletCI@0
    displayName: 'GauntletCI - Analyze PR'
    inputs:
      sensitivity: 'balanced'
      failOnBlock: true
      workingDirectory: '$(Build.SourcesDirectory)'
      gauntletciVersion: 'latest'

How annotations look in Azure Pipelines

Block findings appear as red inline errors in the pipeline run summary. Warn findings appear as yellow warnings. Both link to the source file and line number when a path is available.

Pipeline - Build - GauntletCI Analyze

00:01GauntletCI: 3 finding(s) from 42 rules evaluated.

00:01

error OrderService.cs(44): [GCI0001] Behavior change without test coverage.

00:01

error PaymentService.cs(112): [GCI0003] Exception path added with no callers updated.

00:01

warning Models/Order.cs(23): [GCI0004] Return type semantics changed.

00:01##[error]GauntletCI: 2 block-level finding(s) detected. See annotations above.

Task inputs

Input	Default	Description
sensitivity	balanced	strict \| balanced \| permissive. Controls the confidence threshold for findings.
failOnBlock	true	Set the task result to Failed when any Block-severity finding is produced.
workingDirectory	$(Build.SourcesDirectory)	Root of the .NET repository. Passed as the working directory for the GauntletCI process.
gauntletciVersion	latest	NuGet version to install. Use 'latest' or pin to a specific version such as '2.1.1'.

Manual install (without the Marketplace task)

If you cannot install from the Marketplace or prefer full control, use the raw script steps below. These work identically to the task.

# Equivalent manual steps if not using the Marketplace task
- script: dotnet tool install -g GauntletCI
  displayName: 'Install GauntletCI'

- script: |
    export PATH="$PATH:$HOME/.dotnet/tools"
    git diff origin/$(System.PullRequest.TargetBranch)...HEAD > pr.diff
    gauntletci analyze --diff pr.diff --no-banner --ascii
  displayName: 'Run GauntletCI'
  failOnStderr: false

Branch policy enforcement

To block PRs from completing when GauntletCI finds blocking issues, add the pipeline as a required build policy on your target branch. In the Azure DevOps project settings, go to Repos > Branches > Branch policies for main, add a Build validation policy, and select your GauntletCI pipeline. Set it to Required.