In an ideal world, I'd be able to add a property to a build from the first build step. Any additional build step would be able to reference that property just like any current property (system, env, etc). Bonus points would be having the dyanmic property available on the build params tab for the build and listed as a property via the REST API.
Is there an easy way to do this that I've missed? I'm already using tags to do this sort of thing but in those cases there is a high probability that any given build will reuse existing tags. If I use tags for this new thing I need to do it will likely generate a brand new tag for every build. That will quickly become annoying.
We are integrating with a legacy BuildBot platform that generates image builds. The tests that are run on TeamCity are run against hardware running a specific image built by BuildBot. For our automated testing, BuildBot notifies TeamCity to start testing the images. It passes along a VCS ref ( i.e., "5a8ffa6" ) and a BuildBot build ID ( i.e., "1325" ). This is easy to do robots. :)
For humans, we want to have the ability to kick off tests on arbitrary refs ( i.e., "5acc34", "master", "refs/dev/someuser/somefeature" ) for which they may not know (or care) which image is being used. However, the image should be compatible with the ref. So we specify the default value for the image to be MOST_RECENT. Our "command executable" receives this via. "%env.bb_build_id%" and is smart enough to know if a build ID is passed to use that but if "MOST_RECENT" is passed, it queries the build database to find out which build is most appropriate for the specified ref. For example, if "master" is passed it will find the most recent stable build off of the master branch.
We are extending our TeamCity installation to do some more custom notification stuff and are finding that it would be a lot easier if we could only have the MOST_RECENT -> BuildBot Build ID logic in one location. Possibly a first step that gets run just with %env.bb_build_id% as an argument. The end result would be an actual build ID, either what was passed in or the result of the MOST_RECENT -> BuildBot Build ID process comes up with.
The end result is that I want to be able to track the actual image (BuildBot Build ID) that any given test was run against without requiring the end-user to have to enter that into the params by hand w/ a custom run.
Options that I've considered:
We could dump this information in the checked out directory, but that seems sorta dirty to me. It also would make that information unavailable to anything connecting by way of the REST API. This option is probably not usable if that is the case.
We could tag the build in the first step via. the REST API. Upside would be that this would be available, but we'd lose access to this from the command executable commandline. (Unless I'm wrong there... can you reference tags somehow via %variables%?) This would be a big downside and would require a lot of scripts changing and I would like to avoid this if at all possible.
We could figure out how to programatically write to whatever contains the build params properties in such a way that TeamCity doesn't die. :)