Sharing checkstyle and gerrit

Preamble

Some time ago, having decided to clean up our code, we chose the Checkstyle code style control system. I think the project is familiar, needs no introduction. Prior to that, we used a common repository in the team, where the code styles, intentions settings for the idea were stored.

Adding to the project checkstyle, we primarily pursued the goal - the ability to turn errors in the design of code style into assembly errors. With a slight movement of the hand, checkstyle was connected to the root pom of the project, the developers were introduced to the innovation, the builds on Teamcity learned how to check checkstyle before a commit.

Yes, that's bad luck: a pest appeared in our ranks. How we fought with him - under the cut.

A malicious change was noticed immediately, when building the next release. The build fell with the message:
')

[ERROR] Habr.java[31:1] (imports) IllegalImport: Import from illegal package - org.apache.commons.lang [ERROR] Habr.java[32:1] (imports) IllegalImport: Import from illegal package - org.apache.commons.lang 

Yeah, I thought, I'll figure you out now. And he took up git blame. The intruder was calculated quickly. Imagine my surprise when it turned out that I was the violator. But I gathered the project before the commit committee, drove the checkstyle.



Naturally, it was an oversight from the category “I checked everything, I’ll add one line here, it will definitely not break anything.” The code is fixed, the release is reassembled, the situation is exhausted. However, the next day the situation repeated with my colleague. In Intelij Idea there is an excellent option “Reformat code”, which can be enabled in the commit dialog. I advise her to all my colleagues, intending to forget about this problem once and for all, but here again - the assembly is not going to, in the log:

 [ERROR] Habr.java[136:27] (whitespace) WhitespaceAround: 'if' is not followed by whitespace. 

Of course, someone forgot to enable this option, someone ignored this letter. But back to the beginning of the conversation - we were going to use checkstyle to transfer the errors in the design of the code to the assembly stage - but it’s not necessary to transfer them to the patch assembly stage.

Teamcity + gerrit to help

Our company has been using gerrit for several years to conduct a code-review on a project. Why not cross code review with checkstyle. Armed with Google and the desire to once and for all solve the problem of curved styles, I set about adjusting this economy. I will omit the bad experience, I will describe the integration option that is still working today.

In this paper we will use the commit status publisher plugin , teamcity, gerrit.

The plugin itself has been included in the teamcity since version 7.1 (if I'm not confusing anything).

We configure start of checkstyle

First of all we create a build plan, in which one of the steps we need to do is checkstyle.



The difference between checkstyle: check and checkstyle: checkstyle lies in the fact that the first one will mark the assembly, in case of violations, the second one will collect the entire project and generate a report on all violations.
The best way is to run the first step checkstyle: checkstyle, the second one is chekstyle: check, which will finish the assembly.

Add commit status publisher

Next to the assembly, through the Add build feature is added the commit status publisher.



The settings are trivial - we specify the address of the gerrit server, the git-root from which the assembly is going, the login under which we will break into the gerrit. Authentication in gerrit using the public key, therefore, on the teamcity server and agents, we generate a pair of keys, and register it in gerrit.

We provide start of assembly

It remains only to configure the assembly so that when a new commit appears on the review, the build starts automatically. To do this, in the Build triggers section, add a new Branch Remote Run Trigger. Adjust it to the refs / changes / * branch.

We convince the teamcity that we are us

Well, the most important thing. Teamcity, using Branch Remote Run Trigger launches personal assemblies, which means that in order for the assembly to start, the teamcity must identify its user as the author of the committee. In order to understand whether teamcity has recognized you or not, you can hover over any commit in your build history. If you see the text TeamCity user: unknown, this means that you need another setting.



In the same dialogue, there is a VCS username line: - we copy its contents and go to the teamcity user profile. In the Version Control Username Settings section, write the copied value to the “Default for all of the VCS roots:”.

We publish reports

One more item is optional - you can set up a teamcity build feature called “XML report processing”, in order for teamcity to parse the checkstyle logs and show style violations in the build results. An example of the settings below.



After these settings, you can try to send the code for review to Gerrit. For some time, the assembly should start, which according to the results will put down +1 or -1 in the gerrit. If time has passed, and the assembly has not started yet - the reason to look in the teamcity log.

By the method described by me, you can also control the execution of unit tests for each commit.