Problems with build.vcs.number.ProjectName

When building our apps, I've been using SubRev to get the latest revision of the checkout from Subversion, and write it into a file that enables this version to be displayed in the UI.  Unfortunately this requires a full checkout on the Agent, and I'm trying to get away from that where possible, as this process is hard to interrupt when you want to cancel a build job.

I thought I'd be able to use %build.vcs.number.MyProject%, but the number provided doesn't seem to bear any relation to the latest revision number in either the trunk or root of the project, or even the latest revision in the repository - it's almost as if the number is picked at random.  Does this indicate a configuration issue with TeamCity and Subversion?

Or, is there another way I can get the latest revision of the code I've just exported (specific to the trunk or branch I'm building from)?

UPDATE - It seems that %build.vcs.number.MyProject% is correct when triggered by a VCS change, but not if I run the builds manually.  Is this expected behaviour?

1 comment
Comment actions Permalink

Richard,

build.vcs.number.* property reflects the revision of the last change included into the build. So, it corresponds to the revision of the portion of the sources checked out for the build. This revision does not change on changes in other parts of the repository.

Do you really need the revision of the entire repository?

I should note that the revision of the entire repository is not strictly defined notion as it at least depends on the time the build was triggered. So the build can use the same sources for itselfm but the repository revisions can be different at different moments as there can be changes arriving in other parts of the repository.


If you still need the revision so far I can suggest one of the following workarounds:

- use an util that can get current repository revision without working copy. Ensure that there were no changes affecting the build configuration between the TeamCity-reported revision and the retrieved one.

- configure entire repository in VCS settings of the build configuration, but set "do not checkout" mode; checkout only build-necessary sources "manually" inside the build script; configure the build configuration to be triggered only on changes in the build-related sources (via triggering rules). The drawback is that this way changes in all directories will be displayed as changes.

- a bit more complex, but more TeamCity using approach: in addition to the usual build configuration checking, setup a separate build configuration that will define the entire repository in VCS settings, but with "do not checkout" mode and no build steps to run. Establish a snapshot dependency from the first to the second. In the main build configuration, get the property for the revision of the entire repository (via dep.env.BUILD_VCS_NUMBER_* property).

0

Please sign in to leave a comment.