Code Inspections diff, previous build

Hi,

on the 'Code Inspections' result page, you can filter for 'inspections with new problems only'. How is the previous build determined for this diff? Can it be configured somehow? We are working with git on different branches, and the referenced build seems to be incorrect quite often.

Regards

Michael

0
14 comments

Hi Michael,

code inspections take branches into account, the referenced build should be the last successful build of the same branch, but special builds are left out (cancelled/personal). If this is not what you are experiencing, could you tell us what version you are running and provide screenshots of an example?

0
Avatar
Permanently deleted user

We are using TeamCity 10.0.4 (build 42538).

We are working with git, and the problem seems to occur when branches are rebased. Since our workflow relies quite heavily on rebasing, we are seeing this quite often.

Often we are seeing diffs completely unrelated to the changes in the branch, sometimes extreme cases like this: "Inspections total: 18270 (+18270 -18202), errors: 0 (-2)".

I would expect TeamCity to use the latest successful build in the current commit history of the current branch.

0

That definitely sounds like an extreme case, but my current testing through rebasing shows the diffs from the last successful build of the current branch (as you would expect). Maybe there is something I'm not doing the same way you do, could you maybe add a step-by-step for reproduction? This is what I've done so far:
Branch b1:
commit c1. (Runs build, reports x inspections)
checkout -b b2 (TC configured to track all branches)
commit c2. (Runs build, reports y inspections)
commit c3. (Runs build, reports z inspections)
checkout b1
rebase b2 (sets c3 as last commit for b1, runs build, reports z inspections, z-x diff, only with c1)

0
Avatar
Permanently deleted user

In your example, the rebase is reduced to a fast-forward, isn't it? Can you try to put an additional commit c4 from c1 onto b1, run a build on that and then rebase, such that there is a new commit c4' on c3? That would match our workflow more closely.

0

Hi Michael, sorry but still works as intended. Did a new commit there, rebased, didn't fast forward, made also sure that there was going to be a change in inspections count, got the count and diff right.

Are you using Inspections with IDEA or with .NET? Even though some of the underlying platform for the inspections is the same, they do run some different implementations. My tests were done with IDEA.

0
Avatar
Permanently deleted user

We are using .net.

Related question: Is the build  mentioned in the upper right corner of the inspections report also the one taken as reference for the diff?

 

Is there a way to get verbose logging Information for this scenario?

0

Hi Michael,

I have been talking with the .net inspections maintainer. The logic is the same for both .net and java, so the problem should be different. He has pointed out that there is some issues when the builds are run in different agents because of some very small missconfigurations. The inspections xml result file can be slightly different and then the comparison produces some strange results, as you are experiencing. Some issues that might be related:
https://youtrack.jetbrains.com/issue/TW-36345 (This describes that exact behavior)
https://youtrack.jetbrains.com/issue/TW-42257 (This second one should have been fixed in v10)

The build used for comparison is the previous one of that same branch. The build displayed there is also the previous one on the same branch, so yes, they should be the same.

Could you check whether the first issue would be the case for you? Could you check whether the builds were run in different agents or the same? Do you see this same behavior on two consecutive builds (on the same branch) by the same agent?

For further investigation, we would need you to provide 2 consecutive inspections XML files from the inspections tool where this behavior reproduces. If you hadn't already, you can generate them as specified here: https://confluence.jetbrains.com/pages/viewpage.action?pageId=74844963#Inspections(.NET)-InspectCodeOptions
If you want to keep them private, please consider sending them through the "Submit a Request" button at the top of the page, or attach them to the issue in our tracker if you think it's the same.

0

Hi Michael,

a quick heads up. Had to amend the previous post as it contained an unfinished statement. The build displayed on the image is indeed the previous from that build configuration in that same branch, so yes, it should be the one used to do the comparison.

0
Avatar
Permanently deleted user

Hi Denis, we have observed the TW-36345, but I don't think this is the root cause of this problem: I have created two commits on a new branch and built them (#197). After that, I have done an interactive rebase, merging these two commits into one and updated the branch with a push -force. The next build on this branch displays the build #197 as previous build, whereas from the git history point of view the build #197 is no longer relevant. The inspection XML files are identical for both builds, and don't seem to contain any reference to a build number or a commit hash.

 

0

The xml files are identical yet the inspections diff shows some differences?

Regarding the build, the build shown is the last build on that branch, not on the previous commit on that branch. The build happened last in that branch, independently of whether the commit is still there or not.

TeamCity stores internally the revision (commit) and links that stored revision to the build, so even if the commit disappears from your repository, TeamCity will still keep its information. There might be issues if you try to run a new build with that revision, as git would fail to load it, but that doesn't remove the information that TeamCity stored about that given build.

0
Avatar
Permanently deleted user

Hi Denis, I think TeamCity ignoring the git history in this case is the underlying problem here (excluding the cases of TW-36345), that is why I asked if the previous build can be configured somehow. We have created a Workaround which finds this build number and uses it for the corresponding failure conditions. Maybe there is a way to do something similar for the previous build.

0

Hi Michael,

if at this point none of this has helped, I'm afraid I can't really offer much more help here. If you feel none of the issues mentioned above reflect your situation, please open a request in our tracker describing the situation https://youtrack.jetbrains.com/issues/TW and support for your use case might be implemented in the future.

0
Avatar
Permanently deleted user

Done that, thank you: TW-49049

0
Avatar
Permanently deleted user

I am encountering the same issue, I created a ticket TW-53112

 

With my scenario:

  • using .NET
  • TeamCity 10.0.5 (build 42677).
  • a "personal" branch that no one is using. No code has been checked in, just re-running the same build pipe over and over again.
  • Using the same custom Code Inspection file, mapped it within the build
  • I did compare the CLI (locally) to the TC reports. The results are different and NO ERRROS are being reported on TC

 

0

Please sign in to leave a comment.