I've run into two gerrit plugins for teamcity 8.  One of them runs the gerrit label from the build agents and has a few qwerks that make life less then optimal for us.   I then found this other gerrit plugin that claims to be written by Jetbrains:

I thought I'd give it a shot -- there aren't any compiled binaries or .zips for it -- so I got the build going; fixed some compiler errors with regards to some changes to a jetbarins "StringUtils" class..   got myself a .zip file..but when I load it into teamcity 8 I get an issue with some  classes not implmenting proper spring interfaces.   I also had to comment out the test cases because they were depending on a jetbrains class called EntityId which I didn't find in the teamcity 8 sdk.  

Before I dig more... I was hoping maybe someone else has already done this?   and will let me leverage their work?  :)



Comment actions Permalink


a project at is still an early prototype not suitable for a production use. I hope it will make it to 8.1 release. At the moment it indeed depends on some non-openapi classes for which there is no maven artefact, so it doesn't compile.

BTW, if you want to just run builds on gerrit changes you can use feature branches for that.

Comment actions Permalink


Drat!   We depend on the build verification feature.  I guess my next step to try is to get unix tools running under windows -- and see if they are compatable enough with the existing plugin to work.   Or I could re-write the existing plugin to use jsch rather then shell out to run SSH.

Using teamcity (or Jenkins) to verify changesets before they are submittd is a very very nice use case.   If I don't have that working -- then the jenkins folks in my company will win!  


Comment actions Permalink

TeamCity 8.0 has a cool new überfeature called MetaRunner, which allows you to create a custom runner from existing build steps. I've created a runner that votes for or against Gerrit changes depending on a build status, so you can use it as a last build step in a build configuration.

You can get it on github, it is in the 'gerrit-verify' directory. Install it as desribed here.

A runner assumes that $HOME/.ssh/id_rsa on an agent machine is a private key for authentication in Gerrit.

Meaning of all the runner parameters should be obvious with only exception "Gerrit commit for verification". To verify commit you need to know its SHA, you can get it from TeamCity build parameter %build.vcs.number.<ordinal number or external id of the Gerrit VCS root>% (more on that here). By default a runner use commit of the first root in build configuration, change it if you need.

Overall setup should look like this:

  • A git VCS root which tracks repository in Gerrit and has branch specification like:   


  • Gerrit Verification runner as a last build step
  • VCS Trigger to run build on new Gerrit changes

Let me know if it works for you.

Comment actions Permalink

Sorry it took so long to get back to you.

It works -- once I changed the hardcoded gerrit hostname....however the approach is inheritly flawed.  :(

Since this runs as a runner -- it can only consider the results of previous build steps in its notion of a "failure".  For example;

1)  If I have a build failure condition for the number of inspections greater then XXX to cause a build failure...  then this build runner won't have access to that failure and it will incorrectly +1 a build
2)  I can't rely on teamcity marking a build failed because of test failures.  Because those are also considered after the build runners are complete.  This has more implications:
          a)  I must have my ant target that runs the junit tests fail if there is a test failure
          b)  Which means I can't leverage the "mute" test feature of teamcity... (because junit/ant will still return a failure)

I'm running with these limitations for now.  However I'm getting complaints because teamcity is incorrectly +1ing patches that increase the number of inspection failures, and there is no way to have teamcity mute problematic tests until they can be fixed.   (our software manages a lot of hardware that lack simulators.. so our tests have to talk to live devices...blech!!!!)...

-Eric Hubbard

Comment actions Permalink

Thanks, I've fixed a hard-coded gerrit server.

You can workaround limitations you mentioned by creating a separate build configuration with a snapshot dependency on your main build and a single build step running gerrit verify. Hope it helps.

Comment actions Permalink

That would have been an excellent workaruond.  I should have thought of that!  :)   I ended up just writing my own plugin...   here is roughly how it looked...   it seems to work well so far.  I haven't tried it with muting of test cases yet.. but our inspection checks now correctly fail the build....etc..etc..  it does rely on me putting the wrod "gerrit" into the build configurations I want it to run against.. and I hardcoded all of our gerrit host information, ssh key locations..etc.. right in the source code...

public class Verifier extends BuildServerAdapter {

    String gerritHost = ...
    String gerritPort = "29418";
    String teamCityUrl =...
    private final SBuildServer myBuildServer;

    public Verifier(SBuildServer sBuildServer) {
        myBuildServer = sBuildServer;

    public void buildFinished(SRunningBuild build) {
        try {

            if (build.getBuildType().getFullName().toLowerCase().contains("gerrit")) {

                String buildId = String.valueOf(build.getBuildId());
                String buildTypeId = build.getBuildTypeId();

                String verified;
                log("Build finished -- successful " + build.getBuildStatus().isSuccessful());
                if (build.getBuildStatus().isSuccessful()) {
                    verified = "+1";
                } else {
                    verified = "-1";

                List<SVcsModification> changes = build.getChanges(SelectPrevBuildPolicy.SINCE_LAST_BUILD, true);
                String patchSet  = changes.get(0).getVersion();

                String gerritCommand = String.format("gerrit review --verified=%s --message=%s/viewLog.html?buildId=%s&tab=buildResultsDiv&buildTypeId=%s %s", verified, teamCityUrl, buildId, buildTypeId, patchSet);

                sendGerritCommand(gerritHost, gerritPort, gerritCommand);

     } catch(Exception e) {
          throw new RuntimeException(e);


Comment actions Permalink

Hey Eric,

here is an implementation of Gerrit verifier in a form of TeamCity build feature: To install a plugin put the zip from artifacts into .BuildServer/plugins and restart the server.

After that you can find a new build feature called "Commit status publisher" which can verify Gerrit commits. Let me know if it works for you.

BTW, sources are here:, feel free to contribute.


Please sign in to leave a comment.