[Feature] - V6 Refactoring

[dazinator]

Refactoring to improve composability and allow extensibility

As discussed on slack channel gitversion 6 ideas channel:

• Move version calculation logic behind gitversion.exe calculate command with -normalize switch to do git repo normalization logic before calculating.
• Move logic to detect native supported build servers and set environment variables behind a new command which is written in the style expected for "gitversion tools" e.g it takes version variables in STDIN and writes them to STDOUT e.g gitversion.exe calculate --normalize | gitversion buildserver
• Refactor gitversion msbuild task to be changed to invoke gitversion calculate to obtain variable values - where gitversion will be invoked as a local or global dotnet tool.
• Documentation around how to write a tool for use with gitversion - should be simply a case of stating that the tool should take variables in STDIN and write them to STDOUT for other tools to use onwards in the pipeline as a convenience (if the tool doesn't have any useful STDOUT of it's own).

[svengeance]

Was there any talk about potential refactoring for the command line parsing? It's all hand made at the moment and I must admit I struggled more with figuring out how to incorporate a new switch/arg than how to incorporate a new feature.

There are 3 main flaws with it imo

• Argument binding is done by hand by repeatedly looping through all args and manually determine if it's a switch or a file/etc
• There's a sort of 2-phase binding between a generic Arguments object, and then a more thorough Options class
• The control flow for it is confusing, with argument binding spanning multiple methods in multiple files

I'd suggest something like https://github.com/commandlineparser/commandline which I've used in the past, but the gist of it is that it supports explicit command definitions (as opposed to chaining more if-statements), property binding, validation, free helptext, you name it.

[arturcic]

We're currently considering System.Commandline

[gitfool]

FWIW, I've used System.CommandLine and like it, although progress to a stable version seems slow.

[asbjornu]

One thing we should do for v6 is to make the path variable passed to our Docker containers obsolete. With only Linux images, this is easy by providing a smart Bash script as an ENTRYPOINT that feeds the gitversion executable with /repo.

I'm not sure how we can provide a smart ENTRYPOINT in a cross-platform way, though. We can of course write a .NET Core executable as an ENTRYPOINT, but that feels overly complex as executing other processes from .NET isn't trivial.

Something to cook our noodles.

[arturcic]

@asbjornu at the moment we build only Linux images, we dropped the support for Windows as the images are too big and too long to build.

[asbjornu]

@arturcic, okay. That's good news! A clever entrypoint.sh should be possible, then. I can start hashing something out when time allows.

[dazinator]

@asbjornu at the moment we build only Linux images, we dropped the support for Windows as the images are too big and too long to build.

Does that include the nano image?

[arturcic]

We don't build for nano at the moment , there were some issues with it

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[johnkors]

Not sure if it has been considered, today it's required to setup-dotnet to have the runtime GitVersion needs, correct?

Wouldn't it make sense to either shipping a self-contained version of GitVersion.exe or having the runner install whatever dependencies it needs to be usable (if not already installed), instead of relying on the consumer to do it?

Command: dotnet-gitversion /home/runner/work/MyProject /output json /output buildserver /config GitVersion.yml
/opt/hostedtoolcache/GitVersion.Tool/5.7.0/x64/dotnet-gitversion /home/runner/work/MyProject /output json /output buildserver /config GitVersion.yml
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' (x64) was not found.
  - The following frameworks were found:
      6.0.0-rc.2.21457.6 at [/home/runner/.dotnet/shared/Microsoft.NETCore.App]

And I did not find it documented in the readme.md or elsewhere that it has this dependency. Maybe make that part a bit clearer, if not possible to do it self-contained?

[asbjornu]

@johnkors, we do have a self-contained exe distribution somewhere, somehow. @arturcic, do you have the details? I have no idea how to make a self-installer work, though I see Cake doing something like that.

[arturcic]

Our tar.gz files, the GitVersion.Cmdline and Portable are self contained. Still for Linux with tar.gz you need to install the dependencies needed to run .net (you can find them on Microsoft docs for each distro)

[johnkors]

If it's indeed self-contained, why does the error tell me to install a specific runtime? Not sure I fully get it. I thought self-contained meant it had the relevant runtime deps bundled in the exe/along with the exe.

[johnkors]

Ah, the GitHub Action uses the dotnet global tool under the hood. I missed that. If it used the self-contained exe instead, I wouldn't need require an additional setup-dotnet, I guess.

[arturcic]

Closing in favor of #2275