Commit Status Publisher
Commit Status Publisher is a build feature which allows TeamCity to automatically send build statuses of your commits to an external system. The feature is implemented as an open-source plugin bundled with TeamCity.
GitHub (the build statuses for pull requests are supported as well)
Azure DevOps (supported statuses: Pending, Succeeded, Failed, Error)
Bitbucket Server and Bitbucket Cloud
Gerrit Code Review tool 2.6+
Perforce Helix Swarm
Starting from version 2022.04, Commit Status Publisher updates the commit status in the version control system as soon as the build is added to the queue, providing you with the most up-to-date information. GitHub, GitLab, Space, Bitbucket Server and Bitbucket Cloud, Perforce Helix Swarm, and Azure DevOps are supported.
Commit Status Publisher supports the GitHub URL in the following format:
For GitHub Enterprise:
For connection, select one of the available authentication types:
Access Token — use a personal access token or obtain a token through an OAuth connection. The token must have the following scopes:
for public repositories:
for private repositories:
If you have a configured OAuth connection to GitHub, you can click the magic wand button to let TeamCity automatically retrieve the corresponding access token.
Use VCS root(s) credentials — choose this option to parent VCS root(s) share access tokens with the Commit Status Publisher. Note that credentials sharing is not available if a VCS root uses anonymous authentication, fetches data via an SSH URL, or authenticates using a regular user password.
Password — Provide the GitHub username and password. Note that the password authentication will not work if connecting to a GitHub Enterprise repository or if the user's GitHub account is protected with a two-factor authentication. In these cases, use an access token instead.
If you use a recent version of GitLab (<= 9.0), it is recommended to use the GitLab URL of the following format:
http[s]://<hostname>[:<port>]/api/v4 as GitLab stops supporting the v3 API in GitLab 11. If you have
/api/v3 in your current TeamCity configurations, they may stop working with GitLab 11+, so consider changing the server URL to
For older versions of GitLab, use the GitLab URL of the format
The GitLab credentials for Commit Status Publisher must belong to a user with a Developer, Maintainer, or Owner role for the project. In addition, to change a commit status for a protected branch, the GitLab user must be included in the Allowed to push list.
To be able to connect to Bitbucket Cloud, make sure the TeamCity server URL is a fully qualified domain name (FQDN): for example,
http://myteamcity.domain.com:8111. Short names, such as
http://myteamcity:8111, are rejected by the Bitbucket API.
In the Commit Status Publisher settings, specify a username and app password for authentication. For Bitbucket Cloud team accounts, it is possible to use the team name as the username and the API key as the password.
If you switch the Authentication Type to "Access Token", TeamCity will display a list of configured OAuth connections to Bitbucket Cloud. Click the Acquire button next to a required connection to obtain an access token.
Commit Status Publisher supports the Bitbucket Server URL in the following format:
http[s]://<hostname>:<port>. Besides the URL, you need to specify a username and password or an access token for authentication.
When you select the Access Token authentication type, TeamCity will display a list of configured OAuth connections to Bitbucket Server / Data Center configured in the project and available to all project users. If a token is already configured, TeamCity will display the information about the user that obtained the token and the connection that provided the token.
To obtain the token for the current user, click the Acquire button. If you are not signed in to your Bitbucket Server / Data Center account, TeamCity will ask for access to it. After you sign in, you will be able to acquire a token for the required connection. TeamCity will update the token information for the connection.
To protect a branch and ensure that only verified pull requests are merged into it, you can specify required builds in your Bitbucket repository settings. To set a TeamCity build as a required build, open the Add required builds page in Bitbucket and specify a build configuration ID as a build key in the Add builds field. In this case, Bitbucket will not allow a pull request to be merged until the build on requested changes finishes successfully.
Personal access tokens can be used for authentication. If a VSTS connection is configured, the personal access token can be automatically filled from the project connection.
You can create a personal access token in your Azure DevOps account. Set the Code access scope to Code (status) in the repositories you are about to send statuses to from TeamCity.`
To establish integration with JetBrains Space, you need to create a predefined connection to it, as described here.
Then, in the build configuration's settings:
Open Build Features and add the Commit status publisher build feature.
Select the JetBrains Space publisher and the created connection.
Specify the name that will be displayed for this service in Space.
Save the settings.
Now, whenever you run a build in this configuration, TeamCity will report the build status to JetBrains Space.
Perforce Helix Swarm
If a build is run on changes in Perforce shelved files, TeamCity can report its statuses as comments to the respective code review in Perforce Helix Swarm.
In the Commit Status Publisher settings, specify:
A repository to use for publishing a build status. Choose the default All attached VCS roots option if you wish to publish statuses for commits in all attached VCS roots handled by a single Swarm server.
Your Helix Swarm server's URL.
Username and cross-host ticket for connection (use the
p4 login -a -pcommand to obtain one)
Whether you want TeamCity to create a test run on the Swarm server and update its status according to the build status in TeamCity. To be able to use this mode, make sure the provided credentials grant administrative access.
Note that Helix Swarm usually creates reviews on shelved changelists whose description contains a special keyword, depending on your setup (for example,
#review). If you want TeamCity to trigger builds on Perforce shelved files automatically, you need to specify the same keyword in the Perforce Shelve Trigger settings as well.
After running a build with Commit Status Publisher on a changelist that has a review in Helix Swarm, TeamCity shows the Swarm Reviews section on the build overview page. From each change, you can navigate to the change page on the Helix Swarm using
Open in Helix Swarm. This works for personal builds on shelved changelists, as well as builds on post-commit reviews: the Swarm integration finds reviews associated with the final revision of the build.
Commit Status Publisher supports Gerrit versions 2.6+. For configuring integration with earlier Gerrit versions, contact our support.
Using Commit Status Publisher
Add the build feature to your build configuration.
Use the default All attached VCS roots option if you want Commit Status Publisher to attempt publishing statuses for commits in all attached VCS roots or select a single repository for publishing build statuses.
Select your system as the publisher and specify its connection details and credentials.
Test the connection
Save your settings.
Example: Configuring Pull Requests Status Publishing to GitHub
The example below demonstrates how to configure sending the status of builds with changes included in your pull request from TeamCity to GitHub.
Use pull requests build feature to configure pull requests branches. Alternatively you can make the branches available by configuring the branch specification in your VCS Root while ensuring that it includes pull requests branches (see also a related blog post).
Add the Commit Status Publisher build feature:
Use the default All attached VCS roots option to publish statuses for commits in all attached VCS roots
Select GitHub as the publisher and specify its connection details and credentials and test the connection:
Save your settings.
Commit changes to your source code and create a pull request in GitHub, then run a build with your changes in TeamCity. The Commit Status Publisher will inform you on the status of the build with your pull request changes:
It will show you whether the check is:
hovering over the commit status will display the build summary
clicking the build status icon or the Details link will open the build results page in TeamCity. This information is also available on the Commits tab of your pull request details.
Similarly to the previous page, clicking the build status icon opens the build results page in the TeamCity UI:
Using Commit Status Publisher with VCS checkout rules
If a build's VCS root has checkout rules configured, Commit Status Publisher will consider only commits that conform to these rules. That is, if the last commit made before the build start does not satisfy the checkout rules, it will not be labeled with the build status; the status will be displayed next to the last satisfying commit instead.
If you need to display the build status next to the last commit of the build (for example, in a pull request), you can adjust the checkout rules so this commit is included into the VCS root's scope. Or, if this is a recurrent issue, consider rearranging your build chain as follows:
Configure the main build with checkout rules.
Configure an utility composite build without build steps and checkout rules but with the Commit Status Publisher feature.
In the composite build, configure a snapshot dependency on the main build.
In the scope of such a chain, Commit Status Publisher will not be bound by the checkout rules and the build status will be displayed next to the very last commit.
TeamCity writes events related to the Commit Status Publisher build feature to the
teamcity-commit-status.log file. Apply the "debug-commit-status" preset to include DEBUG-level events to this log.