Skip to end of metadata
Go to start of metadata

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.

 The supported systems are:

  • JetBrains Upsource
  • GitHub (the build statuses for pull requests are supported as well)
  • GitLab

  • TFS/VSTS-hosted Git (supported statuses: PendingSucceededFailedError)

  • Atlassian Bitbucket Server (formerly Stash) and Atlassian Bitbucket Cloud

  • Gerrit Code Review tool 2.6+




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 will stop 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.



Make sure that the TeamCity server URL is FQDN, e.g. Short names, e.g. http://myteamcity:8111 are rejected by the Bitbucket API.

For Bitbucket Cloud team accounts, it is possible to use the team name as the username, and the API key as the password.



Commit Status Publisher in TeamCity 2018.1 supports Gerrit versions 2.6+. For configuring integration with earlier Gerrit versions please contact our support.



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.



To use the tool:

  1. Add the build feature to your build configuration,
  2. 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
  3. select your system as the publisher, and specify its connection details and credentials
  4. Test the connection
  5. Save your settings.

See the example below to configure sending the status of builds with changes included in your pull request from TeamCity to GitHub.

  1. Configure the branch specification in your VCS Root ensuring that it includes pull requests. Detailed information is available in the Branch specification section of this TeamCity blog post.
  2. Add the 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:

  3. Save your settings.
  4. 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:  
    1) It will show you whether the check is in progress , whether it failed  or is successful 
    2) hovering over the commit status will display the build summary
    3) clicking the build status sign 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 web UI: 

  • No labels


  1. Thank you so much for updating this! You don't know how many days it took to figure out where the status are actually placed. I had no idea that it only showed the status in a pull request or the branches view. On that note, is there any way to show the build status in the commit view? Like if I push a commit how can I get the build status, that runs on every commit, to show?

    1. Sean, thank you for the comment. I fixed the page to (hopefully) make it clear TeamCity can attach build statuses of commits in all systems except for GitHub, where only the pull request status can be published. If you want to get the build status on any commit in GitHub, please submit an issue to our tracker 

  2. I'm glad that this plugin is bundled with TeamCity by default. I would like to understand whether it will work when TeamCity is installed on our company's network and is not publicly accessible? Or do I need to expose some proxy? Is there any documentation on how to do it?



  3. Boris, plugin should work fine in this case. If it doesn't,  please file an issue in the tracker and attach teamcity-server.log covering problems to the issue.

  4. Are there any plans to add TFS/VSTS to the list of supported systems?

    1. Hi Yan,

      there are no such plans at the moment, please file a feature request in issue tracker.

  5. If you have multiple build configurations (say, one on Windows and another one on Mac), it looks like whichever one finishes first wins and sets the status of the PR? That's not great ...

  6. Hello,

    looked into sources, and it seems like SSH auth support for bitbucket is missing. Can you please clarify on that?

    Thank you.

    1. Gleb, not sure what you mean. If you think there is an issue with the code, please post it to our tracker noting the code fragments that cause your concern?

      1. It is not about code. This plugin only has login/password auth option to access bitbucket. Our TC is configured to use SSH key to access bitbucket. I cannot reuse it in this plugin. I've seen that other connectors (to some other repository) have this option. Can I use tracker to post this feature request as well?

        1. Gleb, thank you for clarification. Looks like the Bitbucket REST API does not support SSH auth (unlike Git access to Bitbucket repositories), so it cannot be implemented in our plugin.

          1. Julia Alexandrova thank you very much for info. Sad story (smile) 
            Have a nice day!

          2. Julia Alexandrova - For team accounts, BitBucket offers use of API key. The BitBucket REST API does support API key. As a possible alternative, couldn't the plugin offer option to use API key instead of forcing username/password?

            1. Matt Jackman, Thanks for your comment. The plugin supports using team name as the user name and the API key as the password for Bitbucket Cloud team accounts. Team name/API key can also be used as basic HTTP authentication credentials when configuring a VCS Root, or a Bitbucket issue tracker. I'll update documentation accordingly.

              1. Thank you, Julia Alexandrova, for updating doc. We have A LOT of repos, all under the same team. I'd like status for all my build configurations to go update the specified repo. It appears I need to go back to every build configuration and add this build feature, correct? When I try to add build feature to the template, I'm getting this message: "There are no VCS roots configured."

                1. Matt Jackman Julia Alexandrova I have the same problem, that we have a lot of Repos under the same project. I would like to put the auth from the commit status  publisher in the Build Configuration template. Otherwise I have to maintain 80 authentifications for this build feature!! Is there a way how I can set up the  commit status  publisher for all VCS roots? 

                  Many thanks in advance, 


                  1. Matt Jackmanfrancesco, There is a new feature in TeamCity 2017.2, project-wide default build configuration template. You can add the build feature to the template, and once the template is set as the default one for the project, the feature will be added to all its build configurations and those of subprojects. 

                    1. Julia Alexandrova Not sure whether this will solve my requirement. I can add a template project wide with a build feature. But is it possible to add a "commit status publisher" project wide and it will take automatically the respective VCS root? I'm asking because as I mentioned, I have for one project with 80 Repos with 80 different VCS roots. I'm asking because I still have Version 10.0.6. Thanks in advance. Much appreciate!

                      1. Julia Alexandrova thousand thanks for updating Commit Status Publisher site with the information I was looking for. Speechless how fast you've react- much appreciate! 

                        1. francesco, thank for helping me make our documentation better.

  7. It looks like this plugin supports only builds against the pull request branch head and not the results of the merge of that branch. Is that true?
    "I checked the API side. It works for my tests. This could be also a problem is you run the build for refs/pull/*/merge branch. Please use refs/pull/*/head branch"

    1. Rob Fulwell, it seems that you are referencing a different plugin, which is not a part of our bundle.

  8. Has anyone gotten this to work with GitLab?

    I keep getting a "unable to find valid certification path to requested target" error.

    1. Nicola Fera, please submit an issue to our tracker noting the URL and  TeamCity version.

        1. Thanks! Our developers are looking into it, please watch the issue for updates.

  9. Is there any way to use a configuration parameter for the password? It's really tedious to change the value in every single configuration each time we add a new one (because nobody knows what the password actually is so we end up resetting it every time we had a repository to build in teamcity).

    1. Yes! In the password box you can actually enter a parameter reference. I defined a configuration parameter at the root level and then pasted this into the password box %GithubCommitStatusAuthToken% and it works!

  10. Thought i'd mention for anyone that had the same problem as I did - capitalization of repository name is really important! I had capitalized my repository name in TC (when integrating as a bitbucket cloud VCS root), but the BitBucket API to push the build statuses too, requires lowercase. Hope that helps someone.

  11. For Bitbucket Cloud team accounts, it is possible to use the team name as the username, and the API key as the password.


    Bitbucket now uses OAuth2, so the API Keys section has disappeared in the team settings.

    How do we now authenticate this plugin to a Bitbucket Cloud account?

  12. We would like to include `Test failures` instead specifying the build failed has on a pull request in Github. Is there any workaround for this of stuff(using API)? 

  13. Hi TeamCity team,

    We are using TFS Git vesrion control system with TeamCity. TFS hosts repositories and handles pull requests, TeamCity builds all the configurations.


    We have installed Commit Status Publisher as well to post build status back to pull request.

    We have configured Pull Request policy in TFS to always track TeamCity build status and not allow to merge pull requests without successful build


    But appears that TFS doesn't give a shit to this notification (smile) I can merge pull requests with ANY build status: not started, funning, failed, completed...

    Am I doing something wrong or there are other limitations?


    This is URGENT. Thanks!

  14. Alexander Larionov, does TeamCity TFS commit status publisher properly reports statuses of PRs for builds?

    If so you could configure TFS/VSTS branch policy for external system. If branch policy does not work please contact MSFT support since they are more confident in features which they do.

  15. Hi Dmitry,


    Looks like Commit Status Publisher posts correct statuses, at least at first sight...

    What does not work - REQUIRED status on Pull Request... I've read somewhere that it could happen if for some reasons Commit Status Publisher sends "notApplicable" which ignores "mandatoriness" of this build.


    What are the cases for "notApplicable" status posted?

  16. quick question, did someone try to remove the check box under VCS configuration of the build:

    Default Branch Settings

    after i removed it (since we don't need to run builds on the master/default branch) the pull request status stopped updating...

    any idea?


  17. in the documentation, in the last line, bold, does that mean it won't notify Github on success/fail of branch build?

    Disable Building in Default Branch

    By default, TeamCity will run builds in the default branch: the Default Branch Settings section, available since TeamCity 2017.1, has the option Allow builds in the default branch enabled.

    If this behavior is undesirable, you can uncheck this box and the default branch will not be shown in the UI. This can be useful if you want to build pull requests only. 

     (info) Note that unchecking the option will affect all the aspects concerning the default branch, including:

    • build chains: if a chain is triggered in a branch, and this branch does not exist in one of the configurations that is a part of the chain, previously TeamCity fell back on the default branch. If the default branch in this configuration is not allowed, building the dependency will fail
    • the behavior of the Run dialog: the run custom build dialog will be displayed asking to select a branch
    • triggers and notifications.
  18. Does/will the commit status publisher support github deploy keys (ssh keys) for authentication? thanks Rob

    1. Hi Robert, Commit Status Publisher uses  GitHub REST API that does not support ssh-based access and ssh keys based authentication.  
      The most appropriate approach to authentication in Commit Status Publisher for GitHub is to use OAuth2 generated access tokens.


      1. Thank you for the information Anton. Much appreciated. Naturally I was hoping for a different answer (smile)

  19. Please add instructions for GitLab.  I extrapolated from the GitHub instructions and it passes the built-in test; however, I get a 404 error in TeamCity Dashboard when it tries to publish.  My build agent's faceless account has a personal access token with API level access.  I've granted the build agent's faceless account 'Maintainer' access in the repo (although I think 'Developer' should be sufficient).

    TeamCity Version: TeamCity Enterprise 2018.1 (build 58245)

    GitLab Version: 11.3.5-ee 7b10203

    1. Hi Karen, the developer access should indeed be sufficient.  Does Test Connection on Commit Status Publisher edit build feature form also returns an error?

  20. BitBucket has deprecated the API key for teams. Is there a way to configure this plugin to work with teams who have two factor authentication enabled? I've created an app password, but this is rejected by the build feature with the message:

    Bitbucket Cloud publisher has failed to connect to "" repository: HTTP response error, response code: 401, reason: Unauthorized

    1. Hi Mike, do you mind to check:

      • if you use your own username with that app password, 
      • and if the app password has at least Repository read/write permissions.

      1. You correctly identified my stupidity. I used the generated app password label + password rather than my username and the app password.

  21. Hi, I'm trying to set this plugin work with our TeamCity and Bitbucket, but constantly getting 403: Forbidden when trying to test the connection. Could you please help to troubleshoot that?


    1. Hi Nikita,

      What kind of Bitbucket? Bitbucket Server or Bitbucket Cloud? It also seems to me that the credentials you are using do not have enough permissions to publish statuses.