Added a new command line argument -assemblyVersionFormat #315
Conversation
|
This is supported via config now. Do you think it is worth having both config and command line option? |
|
I would have thought consistency, in terms of task, exe and gem, via the config file would be the best approach. |
|
Does that mean, I would need to adjust a config file, and then run the command line exe, and it will honour the setting from the config file? Seems like a bit of a hassle for someone who just wants to plug the command line tool into a team city build step - i.e the need to add another step first to set the config file appropriately.. |
|
In a TeamCity build configuration the config file would be another artefact of the build, checked directly into source control. That way you would have full history of changes that have been made to it. I don't see that being a problem. Sent from my Windows Phone From: Darrellmailto:notifications@github.com Does that mean, I would need to adjust a config file, and then run the command line exe, and it will honour the setting from the config file? Seems like a bit of a hassle for someone who just wants to plug the command line tool into a team city build step - i.e the need to add another step first to set the config file appropriately.. Reply to this email directly or view it on GitHub: |
|
Hi @gep13 - perhaps I am not understanding so go easy on me haha The problem I see with that approach is how it would work in a scenario where you have multiple build configurations (of the same repo) in team city, and you want to use different config per build configuration. For example, perhaps for my CI build I want to stamp my assemblies with different info / version number formats than I use for my "Release" build. Perhaps if you made it so that you can pass an argument to the command line tool to tell it which config file to use? That would then allow you to have multiple config files in your repo - 1 for each build configuration that you need, and then set up Team City like so: Do you think my concern is valid or am i overthinking it? (I should also say that all this stuff is very new to me!) |
|
I am happy to pull this in, I just was questioning if we needed it. Sounds like it has valid use cases. @dazinator can you rebase? |
|
Sure, i will attempt a git rebase - not done that before so will need to read up a bit first. |
|
Ok, so rebased and resolved a merge conflict using git bash on windows. I'm learning some serious sit skills via this PR haha. |
Interesting, I hadn't thought of that. I don't personally do this, but I think I can see why you would require. This, as such, we would need either the ability that you suggested, or allow a per branch configuration to be defined in the yaml file. If this is something that we think is required for a future version, I would suggest opening a new issue so that we can track it.
Rebase, FTW! (Although, can be very dangerous, so take care 😄) |
|
@SimonCropp @andreasohlund you guys happy for this to come in. I think it is all good. |
|
Looks good! |
SimonCropp
changed the title
Added a new command line argument -assemblyVersionFormat that can be used to specify which GitVersion variable is used when setting the AssemblyVersion attribute.