Jenkins

Liegt Ihr Repository auf GitHub und läuft nur der Build auf Jenkins, 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.

Jenkinsfile (declarative pipeline):

pipeline {
    agent any

    environment {
        CODECHARTER_API_KEY = credentials('codeguard-api-key')
        CODECHARTER_VERSION = '1.0.12'
    }

    stages {
        stage('Install CodeCharter') {
            steps {
                sh '''
                    curl -sSL -H "Authorization: Bearer $CODECHARTER_API_KEY" \\
                        -o codecharter.tar.gz \\
                        https://codecharter.tools/api/v1/cli/linux-x64/$CODECHARTER_VERSION
                    mkdir -p codecharter-bin && tar -xzf codecharter.tar.gz -C codecharter-bin
                    chmod +x codecharter-bin/codecharter
                '''
            }
        }

        stage('CodeCharter analyze') {
            steps {
                sh '${WORKSPACE}/codecharter-bin/codecharter analyze MySolution.sln --fail-on error --output sarif --output-file codecharter.sarif'
            }
            post {
                always {
                    archiveArtifacts artifacts: 'codecharter.sarif', allowEmptyArchive: true
                }
            }
        }
    }
}

analyze erwartet den Pfad zu einer .sln-, .slnx- oder .csproj-Datei, kein Verzeichnis.

Lassen Sie CODECHARTER_API_KEY wie gezeigt im globalen environment-Block: derselbe Key autorisiert den CLI-Download und holt zur Analysezeit eine kurzlebige Lizenz vom Portal. Ohne den Key schlägt analyze mit Exit-Code 6 fehl.

API-Key beschaffen

1. Im Portal unter API Keys einen Key erzeugen.
2. In Jenkins: Manage Jenkins → Credentials → Add credentials, "Secret text" mit ID codeguard-api-key.
3. In der Pipeline mit credentials('codeguard-api-key') referenzieren wie oben.

Warnings Next Generation Plugin

Wenn Sie das Warnings NG Plugin installiert haben, können Sie SARIF direkt anzeigen lassen:

post {
    always {
        recordIssues(
            tools: [sarif(pattern: 'codecharter.sarif', name: 'CodeCharter')]
        )
    }
}

Damit landen Findings im Build-Overview, im Trend-Chart und auf den PR-Seiten (wenn Sie ein Bitbucket-/GitHub-Plugin installiert haben).

Exit-Codes

Für das Gating in der Pipeline liefert codecharter analyze:

Caching

Caching lohnt sich, wenn Sie Regelprofile aus dem Portal nutzen: die heruntergeladenen Regel-Bundles liegen neben Ihrer Solution in .codecharter/cache. Mit dem Job Cacher Plugin:

options {
    cache(maxCacheSize: 200, caches: [
        [
            $class: 'ArbitraryFileCache',
            path: "${env.WORKSPACE}/.codecharter/cache"
        ]
    ])
}

Mit warmem Cache überspringt analyze den Bundle-Download, andernfalls werden die Bundles automatisch nachgeladen, was Netzzugriff auf das Portal erfordert.

Self-Hosted-Agents

Standard für Jenkins. Der Agent braucht bei jedem Build Netzzugriff auf codecharter.tools: die Pipeline oben lädt das CLI bei jedem Lauf herunter, und mit gesetztem CODECHARTER_API_KEY holt das CLI zur Analysezeit eine kurzlebige Lizenz vom Portal. Für Agents ohne Internetzugang legen Sie das Binary zusammen mit einer codecharter.license-Datei auf den Agent. Das Archiv ist self-contained, der Agent braucht keine .NET-Runtime.

Multi-Branch-Pipelines

Funktioniert ohne Anpassungen. Jeder Branch wird gegen seine eigene .codecharter/config.yml, .codecharter/codecharter.lock.json und sein eigenes rules/-Verzeichnis analysiert, so wie sie auf dem Branch ausgecheckt sind. Für Pull-Request-Builds begrenzt --git-ref origin/main..HEAD die Findings und das --fail-on-Gate auf geänderte Zeilen.