Help explain artifact numbering

I'm a TeamCity n00b from .NET land, having just crossed over from using CruiseControl.NET for CI on our .NET projects. TeamCity has been a joy compared to CC.NET. I am having a little trouble, however, grokking what happens to the artifacts. I see them in the web app and I see them on disk, but I'm having a hard time understanding why the Artifacts folder has sub-folders named 34, 35, 36, 37, etc. I tried gathering my artifacts into directories labelled with build numbers (build => {build.vcs.number}), but had no luck. How can I make these artifacts available to others if even I don't know where they are going to go?

To make my question sound a little more like a feature request, have you considered using the build format rather than this apparently auto-incrementing number to distinguish the artifacts from different builds? This would make the folder names of the artifacts be more meaningful.

4 comments
Comment actions Permalink

TeamCity stores artifacts using the following directory structure:
<project name>
   <build conf name>
       <build id>
           artifacts

build id is not a build number, it is an internal unique (build number is not unique) id associated with concrete build.

Other users can download artifacts using TeamCity web UI.

0
Comment actions Permalink

Hi Pavel. Thanks for the reply. The web interface is much more meaningful and useful to my users now that I figured out how to zip the output using Nant, as before it was difficult to sell my team on the usefulness of it when they had to download hundreds of individual files. As for the BuildId, I guessed that this is an "internal unique" number used by the system itself, but it really cuts down on the usefulness of sharing out the artifacts at <project name> and having something my users can navigate to find the build they want. Please add it as a feature request that the artifact path look like <project name>/<build conf name>/<fully-evaluated build number format>. You can decide to implement it or not, but it is difficult to question the utility of being able to share the project artifact root on the network.

0

Please sign in to leave a comment.