Run CodeCharter quality gates in Jenkins pipelines

If your repository is hosted on GitHub and only the build runs on Jenkins, you can additionally publish a branded CodeCharter check run and PR comment from this pipeline — see Publish checks from any CI.

Jenkinsfile (declarative pipeline):

pipeline {
    agent any

    environment {
        CODECHARTER_API_KEY = credentials('codecharter-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 also accepts a directory (or no path at all) and searches it for the shallowest .sln/.slnx, but naming the file explicitly is the more predictable choice when the repository holds more than one solution.

Keep CODECHARTER_API_KEY in the global environment block as shown: the same key authorizes the CLI download and lets the CLI obtain a short-lived license from the portal at analysis time. Without it, analyze fails with exit code 6.

Getting an API key

1. Generate a key in the portal under API Keys.
2. In Jenkins: Manage Jenkins → Credentials → Add credentials, "Secret text" with ID codecharter-api-key.
3. Reference it in the pipeline with credentials('codecharter-api-key') as shown above.

Warnings Next Generation Plugin

If you have the Warnings NG Plugin installed, you can display SARIF results directly:

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

This puts findings in the build overview, trend chart, and PR pages (if you have a Bitbucket or GitHub plugin installed).

Exit codes

For pipeline gating, codecharter analyze returns:

Code	Meaning
0	No findings at or above --fail-on
1	Findings at or above --fail-on
2	Usage or input error (invalid options, corrupt baseline, missing lockfile)
3	Solution could not be loaded
6	License error

Caching

Caching pays off when you use rule profiles from the portal: the downloaded rule bundles are stored next to your solution in .codecharter/cache. With the Job Cacher Plugin:

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

With a warm cache, analyze skips the bundle download; otherwise it restores the bundles automatically, which requires network access to the portal.

Self-hosted agents

Standard for Jenkins. The agent needs network access to codecharter.tools on every build: the pipeline above downloads the CLI each run, and with CODECHARTER_API_KEY set the CLI fetches a short-lived license from the portal at analysis time. For agents without internet access, place the binary on the agent together with a codecharter.license file. The archive is self-contained, so no .NET runtime is required on the agent.

Multi-branch pipelines

Works without any changes. Each branch is analyzed against its own .codecharter/config.yml, .codecharter/codecharter.lock.json, and rules/ directory as checked out on that branch. For pull request builds, --git-ref origin/main..HEAD limits findings and the --fail-on gate to changed lines.