TeamCity "Build with changes" custom build format and number
When building with a specific set of changes from an old build, I'd like to use the same version number and build number format I used for that old version (so I may use 1.0.45.{0} for thsi current iteration, but I want to build a 1.0.44.43). Is there a configuration parameter I can use to do this? I tried using build.number and build.number.format but the system ignored both (I used 0 as build number, build number came out as 3).
Please sign in to leave a comment.
Heh, it's been awhile, just ran this again, bump. :p
Hi
You can send a service message with a coustom build number.
Where do I put this? In the properties? In the comment section?
send it to standard console output right from your build script
So I'll have to modify the build script every time I want to run a personal build and give it a specfic version override? I can't change any properties in the "run custom build" window?
I guess I can modify my script to look for a property that comes in via the "run custom build" window, seems like a funny way around this though.
If that is honestly the best solution I'll do it, it's a wonderful ability to roll back to the correct version (being as I compile all the libraries with proper version numbers).
Bump, if for some reason you can't override it with custom config I think it's a bug and will report it (after all that is a config parameter right? If not I'll drop it as a feature request I guess), but I want to make sure I'm not putting the wrong config parameter in first.
Bump.
Hello William,
Currently, there is no ability to set build number via a property specified in custom run build dialog without additional preparations.
As a general solution to the task you mention (when build number is defined by the version sources you checkout), I'd consider making this explicit: store the build number prefix in the sources and set the custom build number to TeamCity via service message that Michael mentioned. THe build number can also include sources revision number, if necessary.
With this approach there can be no necessity to specify the build number manually when running a custom build.
As to your specific question on how to trigger a build with a number specified on the build run. It can indeed be filed into our issue tracker as a feature, but I'd rate it as not very important (prorated to the benefit an average TeamCity user will get out of it).
Current workarounds can be:
- tweak your build script to watch for a specific manual build number property. If specified, use it as the build number instead of default TeamCity one. The logic to change build number will then work since the change in the build script.
- Install autoincrementer plugin mentioned in the issue. Specify build number in a build configuration as a reference to some property. Set default value for the property to an autoinc property. This way, if you specify your custom value for the property, it will be used instead of the default autoincremented one.
This sounds like an excellent solution, I'll code up a simple ANT script to do just that, thanks a ton. :) Don't ask me why I didn't just think of implementing my own variable and outputting it to the console (I guess I didn't want to implement this if there happened to be a way to do this natively).