Take in all build number parts as switches

[AwaNoodle]

If you are using Gitflow and trying to use a tool like GitVersion to generate the numbers, passing in the major and minor would be useful to avoid having to alter or write out the versionNumber.xml. I could do this with the xml file and change the numbers before build or change in a release branch etc but they both seem a bit more fiddly for using Gitflow.

[lholman]

@AwaNoodle I need to think about this in a bit more detail, but fundamentally for OneBuild to add its value it needs to be responsible for versioning, thus the use of the VersionNumber.xml files, sitting next to and checked in to source control, I mention more about it here, in particular "OneBuild ...Intelligently versions locally in the same way it does on the CI server. (during task Set-VersionNumber)". This statement is a subtle but important part of OneBuild's approach, i.e. it enables a developer to execute a local build with a version number that is as similar as possible to that generated from a CI server that is running the build using OneBuild, in particular the major and minor build numbers. Having a realistic build number with local builds is important, especially when you bring database versioning in to play, just running a build locally that uses a default version of say '1.0.0.0' makes automated database versioning almost impossible, among some other scenarios, it's often also a good indication what branch a developer is working on.

If we were to pull versioning out of OneBuilds domain and pass the version number components in then we lose the above, OneBuilds contract becomes a little more complex and we would also rely more heavily on the CI server specifics, another thing OneBuild attempts to simplify.

Does that answer your question, or are you proposing OneBuild uses GitVersion (something I'm not experienced with), have I missed anything?

Thoughts?

[AwaNoodle]

I think that to keep this in line with the spirit of OneBuild, supporting GitVersion would be a possible solution to this issue. That will be the same on the dev machine as it is on the server for the major parts, so you're covered there. Else I think it's a case of generating the version xml on the fly, which isn't really a show stopper either until it gets to local running and the need for those steps to be actionable on the devs machine.

I'm not sure how in practice this would work atm. It seems all ways but looking for / supporting GitVersion in a known location would require some extra bespoke work and that is sort of not the point.

[lholman]

Ok, maybe if you can put together some high level Given, When, Then style BDD detail in here I could get a better idea of what you're trying to do, it's a bit hard to pin down at the moment.

[AwaNoodle]

Given I am using GitFlow and GitVersion is used for version numbers When I run OneBuild Then the GitVersion semver should be used

[lholman]

@AwaNoodle Is this a blocker for you at the moment? I'm not really planning to look at this at the moment as we have quite a lot of WIP, I'll keep it open but tag it as an 'enhancement', as opposed bug or easyfix.

[AwaNoodle]

This is something I could look at myself.....if you have a suggestion for good extension points in OneBuild. I would think that I could look for GitVersion in a known location, if its there, to use it, and then call it to get the SemVer needed.

[lholman]

@AwaNoodle Happy for you to take a look, I'm currently trying to pull together a few fixes in a v1.1 release so my focus is there at the moment (excluding priority bugs) so I won't be able to pull this in immediately. Could you insure documentation is thought about too?

[AwaNoodle]

@lholman If I figure out a way, it'll be documented :)

[lholman]

@AwaNoodle I'm just going through the next issues to pick up and have taken a quick look at https://github.com/GitTools/GitVersion, It seems that it heavily encourages feature branching and use of GitFlow/GitHubFlow git patterns, which OneBuild directly attempts to avoid, in favour of running a stable mainline approach to build. That said, I appreciate there are likely many projects that are in this position.

To support GitVersion, I see the top level task being required.

• [ ] Define how the NuGet GitVersion dependency will be recognised by OneBuild (GitVersion.exe does not seem to be included in the NuGet package https://www.nuget.org/packages/GitVersion/, rather it's Chocolatey install https://github.com/GitTools/GitVersion/wiki/Command-Line-Tool)
• [ ] If GitVersion is found, then extend the Set-VersionNumber Invoke-Build task (https://github.com/lholman/OneBuild/blob/master/OneBuild.build.ps1#L119) to ignore VersionNumber.xml and run GitVersion.exe and pass the default JSON generated when the /output switch is passed.
• [ ] Cover off scenarios for switching between versioning with GitVersion and the basic OneBuild versioning.

A few notes:

• GitVersion.exe is > 2MB, currently OneBuild, minus dependencies is 30KB, it'd be nice to make GitVersion opt in, i.e. rather than a dependency to OneBuild itself, OneBuild could scan the solutions \packages folder. Is GitVersion a solution or project NuGet package?

All the above said, is there a priority for this, anyone else wanting it, are there more pressing issues?