Commit Status Publisher

GitHub

Commit Status Publisher supports the GitHub URL in the following format:

• For GitHub.com: https://api.github.com

• For GitHub Enterprise: http[s]://<host>[:<port>]/api/v3

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: public_repo and repo:status

  • for private repositories: repo

• 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.

GitLab

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 api/v4.

For older versions of GitLab, use the GitLab URL of the format http[s]://<hostname>[:<port>]/api/v3.

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.

Bitbucket Cloud

In the Commit Status Publisher settings, specify a username and app password (or token) 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.

Bitbucket Server

Commit Status Publisher supports the Bitbucket Server URL in the following format: http[s]://<hostname>:<port>. Apart from the URL, you need to specify a username and password (or token) for authentication.

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.

Azure DevOps

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.`

JetBrains Space

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:

1. Open Build Features and add the Commit status publisher build feature.

2. Select the JetBrains Space publisher and the created connection.

3. Specify the name that will be displayed for this service in Space.

4. 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 -p command 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.

Gerrit

Commit Status Publisher supports Gerrit versions 2.6+. For configuring integration with earlier Gerrit versions, contact our support.