Skip to content

TeamCity

CodeCharter in a TeamCity build step.

Use a Command Line build step with a custom script. The agent must have the .NET 9 SDK installed (or use a Docker wrapper image with the SDK). The script below runs in bash; adjust the shebang or runner type for Windows agents.

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

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']"

Replace MySolution.sln with the path to your .sln, .slnx, or .csproj file. For machine-readable reports, add --output json:codecharter.json or --output sarif:codecharter.sarif and publish those files as artifacts instead of (or alongside) the console log.

Because the script runs with set -e, the build fails when analyze exits non-zero: exit code 1 means findings at or above the --fail-on level, 2 a usage error, 3 the solution could not be loaded, and 6 a license error.

API key

In TeamCity: Project → Parameters → Environment variable CODECHARTER_API_KEY, type "Password". Store it at project level so all build configurations can access it.

The analysis requires a license. With CODECHARTER_API_KEY set in the build environment, the CLI automatically obtains a short-lived license from the portal at the start of the run; no further setup is needed. If no valid license is available, the CLI exits with code 6.

Caching

TeamCity has no built-in file cache mechanism equivalent to GitHub Actions' actions/cache. The .codecharter/cache/ directory next to your solution, which holds the rule bundles downloaded by codecharter restore, will not automatically persist between builds on a clean agent.

To cache the CodeCharter cache directory, you need a pinned, non-ephemeral agent that keeps its workspace between builds. Disable the clean checkout option in the build configuration so the work directory persists.

Without a persistent workspace, codecharter restore downloads the rule bundles again on every build. With a warm cache, the run skips that download.

Self-hosted agents

Works without any changes. The agent needs internet access to codecharter.tools, or you can mirror the release archive into a local artifact repository. Note that the CLI still contacts the portal at run time to obtain its short-lived license from your API key; for fully offline agents, provide a codecharter.license file instead (for example via the --license flag).