Bug? Runner Type "Inspections (IntelliJ IDEA)" with Project File Type "Gradle" wipes .idea directory at start of run.


This is on TeamCity 9.1.4. We can't upgrade to 9.1.5 because we're still on IDEA 14 until our upgrade license purchase is approved.

Just as the subject states, using the runner type "Inspections (IntelliJ IDEA)" with the project file type set to "Gradle" fails silently with no inspections actually performed because the contents of the entire ".idea" directory are wiped at the start of the step execution. I've watched it happen closely several times now and have narrowed down exactly which line from the build log matches up with the directory being wiped. Here is what I'm seeing.

(1) The build starts and I watch for the following to appear in the build log.

[08:32:21]Step 1/1: Inspections (IntelliJ IDEA) (1m:38s)


[08:32:50]Starting: /buildusr/jdk18/bin/java -Dagent.home.dir=/buildusr/TeamCity/buildAgent <...>

[08:32:50]in directory: /buildusr/TeamCity/buildAgent/work/a13e59a15bf4a1f4

(2) From the command line, I quickly switch to the directory where this build is occurring and check the contents of the ".idea" directory.

-bash-4.1$ cd /buildusr/TeamCity/buildAgent/work/a13e59a15bf4a1f4
-bash-4.1$ ls -al .idea/
total 112
drwxr-xr-x 8 buildusr buildgrp  4096 Jan  7 08:18 .
drwxr-xr-x 6 buildusr buildgrp  4096 Jan  7 08:18 ..
-rw-r--r-- 1 buildusr buildgrp  3347 Jan  7 08:18 codeStyleSettings.xml
-rw-r--r-- 1 buildusr buildgrp   711 Jan  7 08:18 compiler.xml
drwxr-xr-x 2 buildusr buildgrp  4096 Jan  7 08:18 copyright
-rw-r--r-- 1 buildusr buildgrp   457 Jan  7 08:18 dataSources.ids
-rw-r--r-- 1 buildusr buildgrp   289 Jan  7 08:18 dataSources.local.xml
-rw-r--r-- 1 buildusr buildgrp   923 Jan  7 08:18 dataSources.xml
drwxr-xr-x 2 buildusr buildgrp  4096 Jan  7 08:18 dictionaries
-rw-r--r-- 1 buildusr buildgrp   220 Jan  7 08:18 encodings.xml
drwxr-xr-x 3 buildusr buildgrp  4096 Jan  7 08:18 fileTemplates
-rw-r--r-- 1 buildusr buildgrp 12828 Jan  7 08:18 findbugs-idea.xml
-rw-r--r-- 1 buildusr buildgrp    24 Jan  7 08:18 .gitignore
-rw-r--r-- 1 buildusr buildgrp   613 Jan  7 08:18 gradle.xml
drwxr-xr-x 2 buildusr buildgrp  4096 Jan  7 08:18 inspectionProfiles
-rw-r--r-- 1 buildusr buildgrp  2314 Jan  7 08:18 misc.xml
-rw-r--r-- 1 buildusr buildgrp   383 Jan  7 08:18 modules.xml
-rw-r--r-- 1 buildusr buildgrp    13 Jan  7 08:18 .name
drwxr-xr-x 2 buildusr buildgrp  4096 Jan  7 08:18 runConfigurations
-rw-r--r-- 1 buildusr buildgrp   564 Jan  7 08:18 runConfigurations.xml
drwxr-xr-x 2 buildusr buildgrp  4096 Jan  7 08:18 scopes
-rw-r--r-- 1 buildusr buildgrp  8794 Jan  7 08:18 uiDesigner.xml
-rw-r--r-- 1 buildusr buildgrp   180 Jan  7 08:18 vcs.xml

(3) That all looks good. But then a few seconds later, this entry appears in the build log.

[08:32:55]Starting up IntelliJ IDEA 14.1.4 ...done.

(4) Before the next line even appears after that in the build log, I see this happen to the ".idea" directory.

-bash-4.1$ ls -al .idea/
total 8
drwxr-xr-x 2 buildusr buildgrp 4096 Jan  7 08:19 .
drwxr-xr-x 6 buildusr buildgrp 4096 Jan  7 08:18 ..

(5) This causes the inspection to fail silently later in the build.

[09:06:05]Opening project...done.
[09:06:05]Initializing project...Loaded shared project profile 'Project Default'
[09:06:05]Inspecting with profile 'Project Default'
[09:06:08]Process exited with code 0

I know for a fact that the inspection can't possibly only require one second to execute. There are also none of the "Analyzing code ... XX%" log entries that usually appear in the logs during other projects of ours that also use the "Inspections (IntelliJ IDEA)" runner type, but NOT the "Gradle" project file type.

Because the inspection was failing silently, it took us a while to catch on that the inspections were not actually getting executed. When I realized this and then my analysis revealed this issue with the wiping of the ".idea" directory, I experimented with switching the build step configuration to use the "Inspection profile path" instead of the "Inspection profile name". This still causes the .idea directory to get wiped, but the build at least fails non-silently.

[18:38:08]Failed to load profile from '/buildusr/TeamCity/buildAgent/work/9eee278eb7565bb4/.idea/inspectionProfiles/Project_Default.xml'

I'm assuming this must be a bug of some sort. I'm guessing that the IntelliJ IDEA 14.1.4 startup is attempting to update all the project files in the .idea directory from the build.gradle file and is silently crashing or something during this step, but I don't know where to look to troubleshoot any further. Anyone have any clues?
Comment actions Permalink

More information about our environment which may or may not be relevant...

-bash-4.1$ cat /proc/version
Linux version 2.6.32-504.12.2.el6.x86_64 (mockbuild@x86-027.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-9) (GCC) ) #1 SMP Sun Feb 1 12:14:02 EST 2015
-bash-4.1$ which java
-bash-4.1$ java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Comment actions Permalink

Hello Kyle,

It is a known bug https://youtrack.jetbrains.com/issue/TW-42095. Unfortunately it's not been fixed yet. As current workaround you can copy profiles outside of the .idea directory or use IDEA model.

Comment actions Permalink

Awesome. Thanks very much for pointing that out. I guess I need to learn to search the issue database a little better.

We finally upgraded from IntelliJ IDEA 14 to 15, so I was able to upgrade our TeamCity server from 9.1.4 to 9.1.5. The issue presents itself differently in 9.1.5, but the end result is still the same: inspections for gradle projects are still very much broken.


Please sign in to leave a comment.