Did you also know that you can have these inspections server-side as part of a continuous build process? With TeamCity you can run the same set of inspections on the server, and have the build fail, based on the criteria you define. This can be critical errors or even too many warnings.
1 – Defining a Scope
Once you do so you’ll see project’s files on the right (click the image to see a larger version).
2 – Creating an Inspection Profile
Go back to File -> Settings and find the Inspections entry. Create a new inspection profile JS Inspection and remember that name, we’ll need it at step 6.
Attach the scope defined at step 1 to rules you’re interested in.
3 – Defining Warnings and Errors
Every inspection rule can have a varying degree of severity, ranging from simple typos to critical errors. It is important to differentiate between warnings and errors since TeamCity allows us to treat them differently when specifying build failure conditions.
Some teams may consciously decide to pay attention (and hence fail the build) only to actual errors, which might cause browser misbehaviours at run-time. Examples include the famous last comma in array or object literal in IE issue. Other teams may treat errors and warnings equally so that neither of them ever make it to release. Whatever your preferences are, make sure inspection rules are in sync with them.
4 – Sharing and Locking Inspection Profile
When scopes and inspection profiles are defined the default location for IDE to keep this data is
.idea/scopes/<scopeName>.xml for scopes and
.idea/inspectionProfiles/<profileName>.xml for inspection profiles. These files can now be committed to source control for TeamCity to read them.
Locking inspection profile is a different story. Your IDE may have certain plugins disabled which will consequently make their inspections disappear from inspection profile screen. However, when TeamCity runs server-side code inspections it does so by firing up its own Intellij IDEA instance. This instance comes bundled with a default set of plugins and, therefore, a default set of inspections applied to your code in addition to those specified by you. As a result, it may be surprising to see TeamCity running inspections that were never part of the profile. So locking it means “Run only explicitly enabled inspections”.
As a result, you need to share and lock your inspection profile as shown on the following screenshot.
5 – Committing “.idea” directory to source control
After inspection profile is configured, shared and locked you need to check in an
.idea directory into source control for TeamCity to read inspection definitions from there. Once again, the only file that should not be committed and is excluded by default is
.idea/workspace.xml since it only contains your personal project settings.
6 – Configuring TeamCity Build Configuration
Once we have the inspections ready and committed to source control, we can now do the set up on the server-side. To do so, add a new Build Step and select Inspections (Java).
Configure this step similarly to the screenshot below (click the image to see a larger version).
The only thing that needs to be specified on this screen is Inspection profile name from step 2. You can now try to run your build configuration to see if there are any build errors. When all goes well you can navigate to inspection results from TeamCity “Overview” screen.
When browsing inspection result, you can open the offending line right in your IDE if you have TeamCity IDE plugin installed and logged in to your TeamCity instance.
7 – Configuring TeamCity Build Failure Conditions
Now that we can run inspections on the server, we can define build failure conditions using “Fail build on metric change” introduced in TeamCity 7. As mentioned in Step 3, inspection errors and warnings are treated as two separate metrics so we can define each of them in its own way.
Subscribe to Blog updates
Kotlin DSL for Beginners: Recommended Refactorings
Imagine you have just switched your TeamCity project over to Kotlin DSL. Your builds run successfully, but what next? What small refactorings can you apply to your Kotlin DSL code to help keep it clean and tidy? In this article, we'll discuss the next steps you can take. 1. Remove disabled build st…
TeamCity integration with .NET, Part 3: Deploying projects
Today we are wrapping up our .NET integration demo. In this series, we've been explaining how TeamCity can integrate with .NET and walking you through a tutorial. To catch up with the demo, read the previous posts: Part 1: New approach and demo Part 2: Testing and building projects This project ha…
New TeamCity REST API documentation
TeamCity REST API is a powerful tool which lets you integrate external applications with the TeamCity server and create diverse script interactions. To make this instrument more useful and easier to understand, we have reworked the REST API documentation. Compared to a general guide we had in the p…
TeamCity integration with .NET, Part 2: Testing and building projects
In this blog series, we talk about the new approach we use to integrate TeamCity with .NET. Part 1 describes the .NET runner, that covers most of the core integration functionality, and introduces a demo project. In Part 2, we will dig deeper into the demo project and explore its Test and Build conf…