Join the DZone community and get the full member experience.Join For Free
Learn how error monitoring with Sentry closes the gap between the product team and your customers. With Sentry, you can focus on what you do best: building and scaling software that makes your users’ lives better.
But can you take it to another level? Can you make TeamCity run the same set of inspections and fail the build if critical errors are found or there are way too many new warnings? Oh yes, absolutely, and I’m about to show you all the steps and details involved.
I’m going to use WebStorm in this demo setup but you can follow the same process using either Intellij IDEA Ultimate Edition or PhpStorm.
1 – Create Scope
So specify first what is it you do want to analyze (click the image to see a larger version):
2 – Create Inspection Profile
Create a new inspection profile named "JS Inspection". Remember that name, we’ll need it at step 6.
Attach the scope defined at step 1 to rules you’re interested in.
3 – Error or Warning?
Every inspection rule can have a degree of severity specified, varying from simple typos to critical errors. It is important to differentiate between warnings and errors since TeamCity allows to treat them differently when specifying build failure conditions.
Some teams may consciously decide to pay attention (and hence fail the build) only to the actual errors, causing browser misbehavior at run-time, such as famous “Last comma in array or object literal” in IE. Other teams may treat errors and warnings equally so that none of them ever makes it to release. Whatever your preferences are, make sure inspection rules are in sync with them.
4 – “Share” and “Lock” Inspection Profile
Inspection profile needs to be “shared” and “locked”, as is shown on the screenshot below.
“Sharing” profile creates ".idea/inspectionProfiles/JS_Inspection.xml" and “locking” it writes out all rules selected and their scope into this file so TeamCity doesn’t apply any additional inspections you may not see due to IDE plugins being disabled.
5 – Commit “.idea” directory to VCS
".idea" directory needs to be checked in into VCS repository for TeamCity to read inspection definitions from there (that’s why it was important to “share” the scope and inspection profile in the previous steps). The only file that should not be committed and is therefore excluded by default is ".idea/workspace.xml" since it only contains your personal project settings.
6 – Configure TeamCity Build Configuration
Things get much easier when you switch over to setting up TeamCity build configuration. Add "Inspections (Java)" build step.
Configure this step similarly to the screenshot below (click the image to see a larger version).
In fact, the only thing that needs to be specified on this screen is “Inspection profile name” from step 2. If in doubt, you can copy this name from ".idea/inspectionProfiles/<profile name>"
You can now try to run your build configuration to see if there are any build errors. TeamCity shouldn’t fail if scope (step 1) and inspection profile (step 2) definitions were “shared” and all ".idea" files were committed to VCS repository. When all goes well you can browse inspection results ..
.. and open the offending line right in your IDE if you have TeamCity IDE plugin installed and logged in to your TeamCity instance.
7 – Configure TeamCity Build Failure Conditions
Published at DZone with permission of Evgeny Goldin , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.