[Feature] Change Cli to a new implementation

[arturcic]

Change the Cli to System.Commandline

The commands:

gitversion --help
gitversion --version

gitversion config (the current init)
gitversion remote --user, --token, --pawwsord, --url - this will work as dynamic repo will download the repo, then you can gitversion run (for remote repos you need 2 steps, remote and run)

gitversion run --config --verbosity --noFecth --noNormalize --args:assemblyInfo=true --args:wixfile=somefile

gitversion run --args:assemblyInfo=true --args:assemblyInfoFile="file1" --args:assemblyInfoFile="file2"

gitversion normalize

gitversion [compat] /updateAssemblyVersion /config - this will allow old syntax with [compat]

gitversion [convert] /updateAssemblyVersion /config this will output the corresponding new syntax

[dazinator]

@arturcic what does gitversion run do?

[dazinator]

does gitversion --version output the verison of gitversion itself - or is that meant to trigger the version calculation?

[arturcic]

gitversion run or compute

[arturcic]

gitversion --version outputs the gitversion version

[dazinator]

Do you think we could leave out gitversion remote --user, --token, --pawwsord, --url in v6?
I wonder why the user can't clone their own repo using those params and then run gitversion normalize on it @asbjornu

[arturcic]

we can

[arturcic]

as for
gitversion [compat] /updateAssemblyVersion /config - you can take the command line you use in GV 5.3.2 for eaxmple and it will with the new parser but old syntax

[arturcic]

of this one
gitversion [convert] /updateAssemblyVersion /config - you can take the command line you use in GV 5.3.2 and it will only convert and output the new syntax

[arturcic]

for that we can use this https://github.com/dotnet/command-line-api/wiki/How-To#Middleware-Pipeline

[dazinator]

ok [convert] looks like a nice feature to have, one to implement probably seperately after all the core commands are done

[arturcic]

or we can have something like [debug] or [diag] to debug or diagnose

[dazinator]

Given normalise is only a prerequisite for version calculation and its optional, I think i'd like to see that as an optional switch provided to the run command if yous see what I mean

[arturcic]

ok [convert] looks like a nice feature to have, one to implement probably seperately after all the core commands are done

Yes, and this will help those using version 5.3.x migrate to 6.0

[arturcic]

Given normalise is only a prerequisite for version calculation and its optional, I think i'd like to see that as an optional switch provided to the run command if yous see what I mean

agree

[dazinator]

Yes, and this will help those using version 5.3.x migrate to 6.0

Yep

[arturcic]

but this is just enhancing the current cli. What we've discussed on the slack channel is different - in that case we change the approach - use the tool in pipeline mode

[dazinator]

but this is just enhancing the current cli. What we've discussed on the slack channel is different - in that case we change the approach - use the tool in pipeline mode

Yeah. Do you think we should have a seperate command like run to do the version calc, or should we just have that be the things that run by default if you execite gitversion.exe with nothing else?

[arturcic]

I don't know, I prefer to have in explicit - similar to dotnet run, basically gitversion is the host and it runs the command

[dazinator]

Ok. So the list of commands something like:

• help
• version
• calculate | run (whatever we call this) etc with an option for whether to normalise, and other options for how to write log output because we can't write to STDOUT
• convert
• compat

Everything else is a tool that will take the version variables from somewhere and do something with them.

[arturcic]

Well compat could involve calling the output consuming tools as currently Gitversion does that

[dazinator]

Well compat could involve calling the output consuming tools as currently Gitversion does that

Can we leave out compat for now then? I'm not actually sure what it does, I understand convert will take the old sytax and parse it to the new syntax (assuming there is enough info in the old syntax to do that) - so does compat take the new sytnax and convert it to the old?

[arturcic]

The idea of compat is that let's say you have Gitversion version 5.3.2. you update to 6.0.0 and just add [compat] and it should work. Not sure how easy will it be to implement that, but this one might call [convert] internally

[dazinator]

The idea of compat is that let's say you have Gitversion version 5.3.2. you update to 6.0.0 and just add [compat] and it should work. Not sure how easy will it be to implement that, but this one might call [convert] internally

Ok. Sounds like potentially one we could leave from the core task of getting everything in place, and could come as an enhancement afterwards..

I've posted to slack channel a bit about writing version variables to STDOUT using a control syntax when logging is also enabled to write to STDOUT. Then a gitversion sanitise command could be added which you could pipe the above output into, and it can strip everything and just recover the version variables and nothing else which it can then write to STDOUT for tools further in the pipeline:

gitversion calculate --verbose | gitversion sanitise | toolA |

In this example you might store the output in a variable and write it to the console before piping on to sanitise for it to be useful.

We could also show examples of the variables being converted to different formats

gitversion calculate --verbose | gitversion sanitise | json-to-yml | write-to-yml-file 

Although not sure how much value there is in that.

[dazinator]

Might be good to offer a tool that can take the version variables as input but then select / write a specific one as output.

I believe the old command line has this ability to only output a particular named version variable value.

Although... for powershell users, it would already be very easy for them to output the version variables json into a json object and select just the property they want. Not sure how difficult that would be in other shells.

[asbjornu]

I believe the old command line has this ability to only output a particular named version variable value.

Yes, it's called -showvariable. I don't think it's actually documented anywhere other than in the auto-generated API documentation.

Although... for powershell users, it would already be very easy for them to output the version variables json into a json object and select just the property they want. Not sure how difficult that would be in other shells.

With jq, I think it's even simpler than it is with PowerShell. :)

[github-actions]

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.