How to generate and set a custom label version based on a date format
We're migrating from CC.Net and our build numbers (for a legacy reason I cannot remember), are in the format {major}.{minor}.{5-Digit-Date}.{revision}.
Major, minor and revision are all obvious and easy to set as part of the build label (and as part of the assembly info). However, I'm hoping there's a nice way of generating the 5 digit date that we currently use.
The 5-digit-date is in the format {year}{weekNumber}{day}. So today will be x.x.18483.x (2018, Week 48, Wednesday is day 3). Is there any way I can generate this within teamcity, or programatically assign it to an environment variable, because we use it on all our projects.
We currently assign this value in a .Net CLI via CC.Net, which sets the assembly version. But as TeamCity can set the assembly info details itself, I'd like to drop that CLI tool.
I don't actually know why we do this before anyone asks as it seems like a pointless number, so migrating to teamcity could be a good opportunity to drop it if this cannot be done.
Please sign in to leave a comment.
Hi Dan,
sorry for the delay. I'm afraid that there are multiple ways to achieve this, so that won't be an excuse to drop it.
The easiest way would be to set up a build that has a schedule trigger, every day at 00:00, with a script that calculates the value and as the last step, modifies via the REST API the parameter on the root project, so that it can be referenced from everywhere. It would be important to ensure that the build agent running the build is properly time synced with the server to avoid issues.
This would have the issue that that takes a few seconds to happen and it might take even longer if there aren't available agents to do it early, which might make builds that happen very early on not take the right number. Builds that started the day prior but end after the day change would very likely have the date of the previous (which might be desired or not).The other solution would be to create the script as a parameter in the root project, which build configurations run on the exact moment they need the parameter. It would be more accurate but require a large overhead.Environment variables can also be used if you want to, but consider that builds are running on build agents, not on the server, so they might need to be set up everywhere.
Thanks for the reply. We just dropped that old style of version number and now just use {major}.{minor}.{revision}.{buildCount}.
I did manage to achieve it myself by calling a console app as the first step of every build to return the 5 digit date and set it to an environmental variable. It had to be done on every build or the value seemed to get reverted. Additionally, builds wouldn't get a proper build until a few seconds after they started.
In the end, we decided to just drop that date number as we universally agreed it is pointless. Thankfully our revision number is in the 36000s and the dates all begin with 18xxx, so it won't affect any of the version ordering.