Most recent build is successful, but is not "Last Successful Build"

SuccessfulBuild.png
I have recently upgraded to TeamCity 7.0 (build 21241). I am not sure if this issue was present in version 6.

As you can see in the screenshot above, the most recent build in this particular configuration (1.0.20.977 from Mar 5) was successful. However, when I click the "Last successful build" link at the bottom of the configuration overview page, I am taken to build 1.0.941.12 from Jan 18. Also, when I setup a snapshot dependency on the "Last successful build" from this project, it uses 1.0.941.12. It seems that despite the fact that this build was successful, it is not considered the "last successful build". Why might that be the case? According to http://youtrack.jetbrains.com/issue/TW-15628, the fact that the build number is italicized means it contains "out of sequence changes". I don't understand how this build could have been marked as out of sequence, but that is not accurate; it is using the most recent sources (as you can tell from the last part of the build number, which is the SVN revision). I cannot find any documentation about how a build gets "out of sequence", or how the server treats these builds differently.

I am currently unable to use artifact dependencies targeting the "last successful build" due to this problem.

9 comments
Comment actions Permalink

This is now happening for other build configurations in other projects. It appears that all builds after the server was upgraded to version 7 are being marked as "out of sequence".

I could really use some help figuring out what the problem might be.

0
Comment actions Permalink

David, we've seen this problem recently with other customers. These builds appear because TeamCity thinks they have custom VCS roots, i.e. VCS roots different from those, which are defined in build configuration itself. If your VCS roots or checkout rules do not have parameter references (%ref%), such builds should never appear.

We have a hypothesis why it happens, and a fix for this but we are not quite sure the fix really works.
If possible, please install build #21300 which you can download from this ftp server:
ftp://ftp.intellij.net/pub/.teamcity/nightly/

The build is 7.0.1 RC and it has a fix for possible cause of this bug. Since neither data or configuration files are converted during installation of this build, if something goes wrong you can easily revert to official 7.0 build without data loss. We would appreciate if you try this build and tell us whether the issue is fixed or not.

0
Comment actions Permalink

Thanks Pavel. I am using checkout rules, but neither the VCS configuration nor the rules are using parameters. I actually didn't know you could use parameters in the VCS configuration; but I just saw another post describing it. We have been using checkout rules to control which branch gets built in a particular configuration, but it looks like using parameters might be a better solution. Is that the new recommended method for building different branches from the same VCS root? Am I going to run into this problem again even after I apply the patch if I use that method?

I will download the nightly build and try it out.

0
Comment actions Permalink

If you use parameters in checkout rules or in VCS root settings you can simplify TeamCity administration. There should not be problems like this if you use references. Such builds can only occur if you start them via custom build dialog and if you specify different values for VCS parameters in custom build. In this case this build will be treated as a build with custom VCS settings and it won't be shown on overview. So, unless you start builds with custom VCS settings, you won't see this issue.

0
Comment actions Permalink

Unfortunately installing build 21300 did NOT solve the problem. New builds are still being marked as "out of sequence".

Something might be relevant is that this configuration is building code from two different repositories. Before installing the patch I was using multiple VCS roots; since then I have switched to one VCS root that includes SVN externals.

0
Comment actions Permalink

Well I think we'll need your database dump, or at least results of several sql queries. Having a dump would be much more convenient, but if you can't share the whole database, I'll prepare sql queries to fetch a part of data only.

0
Comment actions Permalink

I think I can send the whole database. The last full backup I did was about 11 MB. Where can I send it?

0
Comment actions Permalink

As a result of bug cause discovery this issue was created: http://youtrack.jetbrains.com/issue/TW-20732

0

Please sign in to leave a comment.