Detect if Your Tests Are Running on a CI System

If you have some slow tests in your suite, you might want to run them only on CI. To do this, you can detect in your test runner if you’re running on a CI system.

CI systems set various environment variables, so if you check for their presence you can tell if your code is running there. Here’s a list of some variables you can use for the most popular CI systems. Thanks to pytest-vw for the initial list - this is a “useful” plugin that skips all your tests on CI, à la Volkswagen.

Azure Pipelines sets TF_BUILD to true - docs.

Bamboo sets bamboo.buildKey - docs.

Buildkite sets BUILDKITE to true - docs.

Circle CI sets CIRCLECI to true - docs.

Cirrus CI sets CIRRUS_CI to true - docs.

CodeBuild sets CODEBUILD_BUILD_ID - docs.

GitHub Actions sets GITHUB_ACTIONS to true - docs.

GitLab CI sets GITLAB_CI - docs.

Heroku CI sets HEROKU_TEST_RUN_ID - docs.

Hudson sets BUILD_ID - docs.

Jenkins sets BUILD_ID - docs. (These is the pipeline documentation, but it applies to non-pipeline mode too.)

TeamCity sets TEAMCITY_VERSION - docs.

Travis CI sets TRAVIS to true - docs.

Also, some systems like Circle CI, GitLab CI, Heroku, and Travis CI set the generic variables BUILD_ID, CI, and others. These are intended to be provider-agnostic ways of detecting if you’re running on a CI environment, but this idiom doesn’t seem very widely adopted, so I wouldn’t rely on it.

Newly updated: my book Boost Your Django DX now covers Django 5.0 and Python 3.12.

One summary email a week, no spam, I pinky promise.

Tags: pytest