Commit Status Publisher is poorly implemented

I manage a few hundred git repos at my company, a large amount of which are automated in TeamCity.

My biggest pain point is the Commit Status Publisher. It is a piece of crap (or a POS).

The problem is this:

If I have N amount of git repos, I have to

  1. add N 'commit status publishers' to N projects,
  2. and enter N amount of usernames,
  3. and enter N amount of passwords.

Not to mention all the clicking just to navigate between all of them.

What needs to happen for the commit status publisher is this:

  1. The username field must be able to accept parameters.
  2. The password field must be able to accept parameters.

Without this I don't see TeamCity in our future plans.

You need to start adding features that make our life easier and not just stagnating.


Comment actions Permalink
Official comment

Hi Christopher,

We are sorry you are having an unpleasant experience with Commit Status Publisher.

In fact it does support parameter references in both username and password fields. 

There is a bit of an inconvenience to actually type parameter reference in the password field, as you don't see what you are typing, but that's it. Otherwise it will work just fine. If it doesn't work for you, please provide us with more details of your particular case. Including the version of TeamCity that you are using.

Also if you are using the same credentials within some project hierarchy, you can always create a template containing Commit Status Publisher build feature alone with these credentials configured. And then attach all necessary build configurations to this template. The only limitation here is that it should be one VCS root in each configuration, as you will not be able to specify it in the template (assuming many different VCS roots are used within that hierarchy of projects). 


Comment actions Permalink

I will test that out.

If those fields support parameters, then you need to update teamcity so it's obvious that they are supported. Right now you are implying it's a hidden feature.

btw: I've looked at putting commit status publisher's into templates. And it generally won't work, because publisher needs a VCS to couple with.

Comment actions Permalink

There is a parameter icon near both fields, so you can pick the parameter to reference instead of actually typing it. What would you suggest to make it even more obvious?

As for the template solution, you are right, but only partially. If all VCS roots in your build configurations are hosted in the same place (e.g. GitHub) and are accessible through the same account, you can keep "<All attached VCS roots>" option in your Commit Status Publisher settings and it will publish statuses to all relevant commits in all attached roots. 

Comment actions Permalink

The Attached image only shows a 'parameter' button for the username, NOT the password field.

And in answer to your second question: Our VCS roots are hosted in different places, not one place.

Comment actions Permalink

My mistake, Christopher, sorry for that. The parameter selector icon near the password field has been seemingly introduced after 2018.2.2 
It will appear in either 2019.1 or 2018.2.3 bugfix release, I will clarify that on Monday and will let you know then. 

But anyway, try typing a parameter reference in the password field. Parameter resolution in all fields of the build feature is in place for quite a while already. 

Comment actions Permalink

Our version is: 
2018.2.2 (build 61245)

Comment actions Permalink

Hi Christopher, I have spoken to our UI team. These parameter selection icons near password and token fields is still a work in progress, as they have to behave differently to the ones near regular textual fields. They will not be released in 2018.2.3, and it is not clear yet if we are releasing them in 2019.1

Comment actions Permalink

Sorry for the resurrection, but I feel like OP's major point was missed: the user has already selected what VCS Root is to be used. That VCS Root has all the needed information (server base URL, username, password) and that information should be used by default. I imagine it's useful to allow the user to type in alternative values, but the existing values should be used by default, right? I think we can all agree on this.

Comment actions Permalink



while OP didn't mention that explicitly, there is a valid point in your comment. First of all, using those credentials is not so clear cut as you stated, let me explain. VCS Roots are used almost exclusively for read operations. This means that under many scenarios, the user defined at the VCS Root might not have write permissions to the repository, which are required for publishing status, and also there is a very wide array of scenarios where auth is not even defined at the VCS Root level (for example, every public github or gitlab repository allows anonymous reads). Under this scenarios, there is no direct ability to use those credentials while the commit status publisher can still be used with different accounts.


This is the core reason to why the Commit Status Publisher requests its own credentials. The intersection of repositories with enabled authentication with a user with write permissions and where those credentials match those of the commit status publisher is not as full as it would initially seem.


As a side note, while not strictly dedicated to it, the introduction of the Kotlin DSL makes this much easier, since you can just code the credentials (or references to them) and then generate as many projects using those as you would like. 


With this in mind, we are not dismissing its usefulness, as there is some overlapping, and we have this feature request to implement it: 


Please sign in to leave a comment.