Wrong build number being displayed following reattachment of VCS Root
We have 81 build jobs that all build from the same Subversion repository and therefore all use the same VCS Root which targets the URL at the top of our repository.
Each individual build job has this VCS root attached and is configured via the Checkout rules to only checkout a specific directory within the repository.
Each of the 81 build jobs has %build.vcs.number% set in the build number format field and previously this resulted in the build number being set based on the latest revision number from the repository path defined in the Checkout rules.
When check-in are made to the path denied in the Checkout rules the Pending changes for each build job are detected and we can select the specific build, likewise we used to be able to just hit the build job run button and the latest build would be run and the version number reflected the revision number in the path defined in the checkout rules.
Recently we cloned a build job and then ran it without any changes being made but when viewed it was setting the build number based on the latest revision number in the entire repository.
The original build job still worked correctly but after various attempts to resolve on the cloned build job we detached and reattached the VCS root to the original build job and following this that build job also shows the latest build number from the repository.
We then edited the VCS root adding a / to the end of the URL path saving, and then removing it again and saving. This caused all 81 build jobs to exhibit the same symptom and now also have the wrong build number.
Note that we have tried setting the build number format to %build.vcs.number.<VSCRootID>% but this did not resolve the issue
Please forgive me if this has already been raised elsewhere but we are at a loss as to why this is happening. Any help with this would be gratefully received as be need the build numbers to reflect the latest revision number from the path in the VCS root + the path in the checkout rules
eg: latest SVN revision= 8472
latest revision of code in checkout rules path: 1701
build number should be 1701 and not 8472
Please sign in to leave a comment.
I've been able to answer my own question here, posting as it may help someone else …
When a build is carried the build number is generated via the revision for the latest build from the repo filtered for the path defined in the checkout rules via %build.vcs.number%.
however if VCS root is altered or detached and then added the build process knows this has happened and checks to see if the checkout rule based build number is older than the date of the settings change and if so it rebuilds based on the last revision in the entire repo. This is because you have affectively told TeamCity you are using a different repo and therefore the old revision numbers may be out of sync.
Once a new check-in is made and detected by the build job the correct revision numbers will subsequently be set.
This can be seen happening in the logs, the vcs log rule change has been detected and if newer than the revision in the build path then it uses the highest version number from the repo.
12:26:30 Finalize build settings
12:26:30 Collecting changes in 1 VCS root
12:26:30 VCS Root details
12:26:30 "GlobalSVN" {instance id=1510, parent internal id=208, parent id=GlobalSVN, description: "svn: https://Server8472.ACompany.local/svn/ProductX"}
12:26:30 Compute revision for 'GlobalSVN'
12:26:30 Upper limit revision: 37800
12:26:30 Latest commit attached to build configuration (with id <= 40043): 37768
12:26:30 VCS root settings in build configuration were changed since latest version 37768, use first revision of changes collecting 37800
12:26:30 Computed revision: 37800