Gitversion: [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[bot]]

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.