Azure DevOps Pipelines

CodeCharter läuft in Azure Pipelines als Shell-Step. Robust und einfach zu pinnen; außer dem CLI-Download braucht der Agent nur ein .NET SDK, das im Snippet unten über UseDotNet@2 installiert wird.

Liegt Ihr Repository auf GitHub und läuft nur der Build in Azure Pipelines, können Sie aus dieser Pipeline zusätzlich einen gebrandeten CodeCharter-Check-Run und PR-Kommentar veröffentlichen, siehe Checks aus beliebigem CI veröffentlichen.

Minimal-Setup

azure-pipelines.yml:

trigger:
  branches:
    include: [main]

pr:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-latest

variables:
  CODECHARTER_VERSION: '1.0.12'

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

  - bash: |
      curl -sSL -H "Authorization: Bearer $CODECHARTER_API_KEY" \
        -o codecharter.tar.gz \
        https://codecharter.tools/api/v1/cli/linux-x64/$(CODECHARTER_VERSION)
      mkdir -p /opt/codecharter && tar -xzf codecharter.tar.gz -C /opt/codecharter
      chmod +x /opt/codecharter/codecharter
      echo "##vso[task.prependpath]/opt/codecharter"
    displayName: 'Install CodeCharter CLI'
    env:
      CODECHARTER_API_KEY: $(CodeCharterApiKey)

  - bash: |
      codecharter analyze MySolution.sln --fail-on error --output sarif --output-file codecharter.sarif
    displayName: 'Run CodeCharter'
    env:
      CODECHARTER_API_KEY: $(CodeCharterApiKey)

  - task: PublishPipelineArtifact@1
    condition: always()
    inputs:
      targetPath: codecharter.sarif
      artifactName: codecharter-sarif

codecharter analyze erwartet den Pfad zu einer .sln-, .slnx- oder .csproj-Datei. Ersetzen Sie MySolution.sln durch Ihren Solution-Pfad; ein bloßes Verzeichnis wird nicht akzeptiert.

Pull-Request-Läufe

Der pr:-Trigger führt bei jedem Pull Request die volle Analyse aus. Um nur die im PR geänderten Zeilen zu melden und zu gaten, ergänzen Sie --git-ref:

codecharter analyze MySolution.sln --fail-on error --git-ref origin/main..HEAD

Sowohl die gemeldeten Findings als auch das --fail-on-Gate beziehen sich dann nur auf geänderte Zeilen. Der Basis-Branch muss im lokalen Clone vorhanden sein, damit git diff funktioniert.

Exit-Codes

Für das Pipeline-Gating gelten diese Exit-Codes:

Code	Bedeutung
0	Keine Findings (oder keine ab --fail-on)
1	Findings ab --fail-on; ohne --fail-on jedes Finding
2	Bedienfehler (ungültige Argumente, keine Regeln gefunden)
3	Analyse fehlgeschlagen (Solution konnte nicht geladen werden)
6	Lizenzfehler, prüfen Sie das CODECHARTER_API_KEY-Mapping

API-Key in Pipeline-Secret

1. Im Portal unter API Keys einen Key erzeugen.
2. In Azure DevOps: Pipelines → Library → Variable groups → New, Variable CodeCharterApiKey mit Wert anlegen, Lock-Icon klicken (macht sie zum Secret).
3. In der Pipeline-YAML auf die Variable referenzieren wie oben gezeigt.

Namenskonvention: CodeCharterApiKey ist der Name der Azure DevOps-Library-Variable (Azure-spezifisch, Pascal Case). Der env:-Block im jeweiligen Step bildet sie auf die Umgebungsvariable CODECHARTER_API_KEY ab, die die CodeCharter-CLI liest. Sowohl der "Install"- als auch der "Run CodeCharter"-Step brauchen dieses Mapping: Der Install-Step authentifiziert damit den Download, und zur Laufzeit erzeugt die CLI damit automatisch eine kurzlebige Lizenz über das Portal. Ohne gültige Lizenz beendet sich jedes Kommando mit Exit-Code 6. Bei abgelaufener Subscription antwortet das Portal auf Download- und Lizenz-Endpunkt mit HTTP 402.

SARIF anzeigen

Azure DevOps hat keinen nativen SARIF-Viewer. Zwei gute Optionen:

Option A. SARIF-Viewer-Extension

Es gibt eine SARIF SAST Scans Tab Marketplace-Extension. Nach der Installation taucht ein "Scans"-Tab neben Tests und Code Coverage auf, der SARIF-Artifacts rendert.

Option B. Text-Report

- bash: |
    codecharter analyze MySolution.sln --no-color --output console --output-file codecharter-report.txt
    echo "##vso[task.uploadsummary]$PWD/codecharter-report.txt"
  displayName: 'Publish CodeCharter summary'

Setzen Sie --no-color, sonst enthält die Report-Datei ANSI-Farbcodes.

uploadsummary hängt den Text an die Build-Summary an. Kein hübsches UI, aber sichtbar.

Caching

Wenn Sie Portal-Profile über .codecharter/config.yml nutzen, lädt CodeCharter Regel-Bundles in das Verzeichnis .codecharter/cache in Ihrem Repository herunter. Der Ort ist nicht konfigurierbar. Dieses Verzeichnis können Sie mit Cache@2 cachen, mit dem Lockfile als Schlüssel:

- task: Cache@2
  inputs:
    key: 'codecharter | "$(Agent.OS)" | .codecharter/codecharter.lock.json'
    path: $(Build.SourcesDirectory)/.codecharter/cache
  displayName: 'Cache CodeCharter rule bundles'

Ohne Portal-Profile gibt es nichts zu cachen.

Self-Hosted Agents

Funktioniert ohne Anpassungen. Der Agent braucht Netzzugriff auf codecharter.tools. Wenn Sie das CLI-Archiv in Ihr eigenes Artifact-Feed spiegeln, entfällt nur der Download: Zur Laufzeit kontaktiert die CLI weiterhin das Portal, um aus CODECHARTER_API_KEY ihre kurzlebige Lizenz zu erzeugen, sofern Sie nicht eine codecharter.license-Datei auf dem Agent bereitstellen.