GitVersionConfig.yaml Should Include Environment Variables

[thefringeninja]

Imagine I have a CI server that automatically pushes packages up to MyGet. Then I have a Pull Request with two commits. Someone else commits to develop so I rebase my PR. This PR retains the same NugetSemVer as before. Pushing the package to MyGet fails because it already has that package. It would be nice to do something like buildMetadata: $ENV['BUILD_NUMBER'] || 1313 in GitVersionConfig.yaml.

[JakeGinnivan]

Would this issue fix the underlying problem: #621

[JakeGinnivan]

I really am in two minds about this. I think GitVersion is a building block tool. There is nothing stopping you from doing in your build scripts, lets say using msbuild

<MyVersion>$(GitVersion.MajorMinorPatch)$(PreReleaseTagWithDash)-build.$(BUILDNUMBER)<MyVersion>

Otherwise you are putting information into GitVersion and it gives it back to you. Thoughts @gep13

[gep13]

Yes, bringing in the environment variable into the Yaml file was not really something that I wanted to do. I was really questioning whether there was anything that we could detect, to indicate that there had been a rebase, and that the version number would/could be the same, and then alter it to account for this. But I don't think that there is anything that we can do, short of caching the SHA's of the commits, and detecting that there had been a re-write of the history, as a result of the rebase, but I don't even want to think about what that would mean.

[asbjornu]

Since GitVersion is able to export version information to build environments, it's not unthinkable that GitVersion should be able to consume version information from the same build environments. Having {buildNumber} available alongside {majorVersion} and all the other version variables in GitVersionConfig.yaml would be neat.

The only thing I don't like about this is that the build environment specific variable would not be available in all build environments, which would cause the version number to differ on the same commit on i.e. local machine and TeamCity.

[gep13]

The only thing I don't like about this is that the build environment specific variable would not be available in all build environments, which would cause the version number to differ on the same commit on i.e. local machine and TeamCity.

And it is this very point that I really don't like. I specifically want my version numbers to be the same, regardless of where the build takes place. All required information should be collected from the repository, not external tools.

[asbjornu]

All required information should be collected from the repository, not external tools.

Yea, I agree that this is an important feature. GitVersion by default would still behave the old way, though. It would be an opt-in to have GitVersion behave differently on different build environments by including build metadata from the environment in the version number.

What if GitVersion failed if the specified variables weren't available at build time? Doesn't sound like a good idea, but it can't hurt having mentioned it as a possibility. 😄

[JakeGinnivan]

What about:

build-number-override: SOME_ENV_VARIABLE, which overrides the build number when specified. If the variable is not defined then it is normal behaviour. Thoughts?

[gep13]

If we are allowing that to happen, then why would the user want to use GitVersion at all, why not simply use the Environment Variable? Or are you suggesting that this Environment Variable would only exist, be set, during some builds, and not all?

[JakeGinnivan]

This would only be able to override the build number, or replace the commit count with something external. The version number and tag cannot be overridden.

[gep13]

Ah, gotcha. Sorry, I read the variable name incorrectly.

[JakeGinnivan]

Still on the fence on this though, as you can do it outside gitversion. It is just far more convenient if you do need this sort of feature

[thefringeninja]

👍

On Mon, Oct 5, 2015 at 8:49 AM, Jake Ginnivan notifications@github.com
wrote:

Still on the fence on this though, as you can do it outside gitversion. It
is just far more convenient if you do need this sort of feature

—
Reply to this email directly or view it on GitHub
#648 (comment)
.

Sent from my regular computer
http://twitter.com/thefringeninja
http://www.thefringeninja.com/

[JakeGinnivan]

@thefringeninja did you want to think through this feature, how it would impact the versions created and how it would look with both continuous delivery and continuous deployment modes then create a fresh up-for-grabs issue which is more complete.

[JakeGinnivan]

Going to track this at #1157 and have marked as up for grabs