TeamCity

Verwenden Sie einen Command Line-Build-Step mit einem Custom-Skript. Der Agent muss das .NET 9 SDK installiert haben (oder ein Docker-Wrapper-Image mit dem SDK nutzen). Das Skript unten läuft in Bash; für Windows-Agents Shebang und Runner-Typ entsprechend anpassen.

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

TeamCity-Build-Step (Command Line):

#!/bin/bash
set -e

# Download
curl -sSL -H "Authorization: Bearer %env.CODECHARTER_API_KEY%" \
    -o codecharter.tar.gz \
    https://codecharter.tools/api/v1/cli/linux-x64/1.0.12
mkdir -p codecharter-bin && tar -xzf codecharter.tar.gz -C codecharter-bin
chmod +x codecharter-bin/codecharter

# Run the analysis (console output)
codecharter-bin/codecharter analyze MySolution.sln \
    --fail-on error \
    --output console \
    2>&1 | tee codecharter.log

# Optionally publish as artifact
echo "##teamcity[publishArtifacts 'codecharter.log']"

Ersetzen Sie MySolution.sln durch den Pfad zu Ihrer .sln-, .slnx- oder .csproj-Datei. Für maschinenlesbare Reports ergänzen Sie --output json:codecharter.json oder --output sarif:codecharter.sarif und veröffentlichen diese Dateien statt (oder zusätzlich zu) dem Konsolen-Log als Artefakte.

Da das Skript mit set -e läuft, schlägt der Build fehl, wenn analyze einen Exit-Code ungleich null liefert: Exit-Code 1 bedeutet Findings auf oder über dem --fail-on-Level, 2 einen Usage-Fehler, 3 dass die Solution nicht geladen werden konnte, und 6 einen Lizenzfehler.

API-Key

In TeamCity: Project → Parameters → Environment variable CODECHARTER_API_KEY, "Password"-Type. Legen Sie ihn auf Projektebene an, damit alle Build-Konfigurationen darauf zugreifen können.

Die Analyse benötigt eine Lizenz. Ist CODECHARTER_API_KEY in der Build-Umgebung gesetzt, holt sich die CLI zu Beginn des Laufs automatisch eine kurzlebige Lizenz vom Portal; weitere Einrichtung ist nicht nötig. Ist keine gültige Lizenz verfügbar, beendet sich die CLI mit Exit-Code 6.

Caching

TeamCity hat keinen eingebauten Datei-Cache-Mechanismus, der dem GitHub-Actions- actions/cache entspricht. Das Verzeichnis .codecharter/cache/ neben Ihrer Solution, in dem die von codecharter restore heruntergeladenen Rule-Bundles liegen, wird auf einem sauberen Agent nicht automatisch zwischen Builds persistiert.

Um das CodeCharter-Cache-Verzeichnis zu cachen, benötigen Sie einen gepinnten, nicht-ephemeren Agent, der seinen Workspace zwischen Builds behält. Deaktivieren Sie dazu in der Build-Konfiguration die Option für einen sauberen Checkout, damit das Arbeitsverzeichnis erhalten bleibt.

Ohne einen persistenten Workspace lädt codecharter restore die Rule-Bundles bei jedem Build erneut herunter. Mit einem warmen Cache überspringt der Lauf diesen Download.

Self-Hosted Agents

Funktioniert ohne Anpassungen. Der Agent braucht Internetzugriff auf codecharter.tools, oder Sie spiegeln das Release-Archiv in ein lokales Artefakt-Repository. Beachten Sie, dass die CLI zur Laufzeit weiterhin das Portal kontaktiert, um über Ihren API-Key ihre kurzlebige Lizenz zu beziehen; für vollständig offline arbeitende Agents hinterlegen Sie stattdessen eine codecharter.license-Datei (zum Beispiel über die Option --license).