[Bug] options /c and /verbosity don't have any effect

[flikkes]

Describe the bug
Using the windows build of gitversion, the option "/c" for selecting a specific commit id doesn't do anything. Still the latest commit is selected. Also, to see what was going on, I tried to change the level of verbosity using "/verbosity Verbose" which also didn't do anything. I tested this using both a current release (5.3.7) and an older version (3.4.0).

Expected Behavior

Gitversion prints out version information calculated from the commit id passed with /c <commit-id>.

Actual Behavior

Gitversion prints out version information calculated from the latest commit.

Possible Fix

As this doesn't seem to be the only option not taken into account, maybe there is a general bug regarding parameters passed to gitversion.exe?

Steps to Reproduce

• Create an empty repository and add some content with several commits (I did around 4 or 5)
• run gitversion.exe /c <commit-id>, where commit-id should be a commit, older that the latest

Your Environment

Ran from powershell.

• Version Used: 5.3.7 and 3.4.0
• Operating System and version (Windows 10, Ubuntu 18.04): Windows 10

[DarwinJS]

This also happens in the gittools/gitversion container.

[asbjornu]

If you change the switches from slash (/) to dash (-), does the behaviour change?

[DarwinJS]

Yes I tried verbosity with both switch prefixes.

[DarwinJS]

@asbjornu - FYI I am actually building a working example for the GitLab eco system. I am finding it challenging to understand how Gitversion decided on the version number. I have a debug mode built in for Gitversion which outputs the configuration - but it sure would be nice to be able to see the decisions it makes for a given scenario.

I am implementing it in a way that a single job does the version determination and passes the version variables back into the pipeline so that any downstream jobs can leverage it no matter what type of technology they are using - so all containers for the linux eco system could then use the version number as well.

The GitLab CI is also implemented as a CI CD plugin Extension - which means it can be included into other pipelines from a central location.

Currently it creates a GitLab Generic Package and GitLab Release. I plan to add a NuGet package as well.

My plan is to do a PR to update your GitLab CI informational page once the example is fully tool-ized.

It is here: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning

[DarwinJS]

Just wanted to leave a "for instance". I am having a difficult time diagnosing why my merges to develop have a totally different sequent (starting with 1.6.) and then revert back to the current (starting with 1.4.) when merging through release and main.

Here is the log with '/verbosity' being ignored:
https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/-/jobs/1387522859

[asbjornu]

This is strange. As you can see by the following test, -verbosity Normal should work. We should probably add a TestCase for the other verbosity levels as well.

GitVersion/src/GitVersion.App.Tests/ExecCmdLineArgumentTest.cs

Lines 39 to 53 in 17cf0df

	[Theory]
	[TestCase("", "INFO [")]
	[TestCase("-verbosity NORMAL", "INFO [")]
	[TestCase("-verbosity quiet", "")]
	public void CheckBuildServerVerbosityConsole(string verbosityArg, string expectedOutput)
	{
	using var fixture = new EmptyRepositoryFixture();
	fixture.MakeATaggedCommit("1.2.3");
	fixture.MakeACommit();
	var result = GitVersionHelper.ExecuteIn(fixture.RepositoryPath, arguments: $@" {verbosityArg} -output buildserver /l ""/tmp/path""", logToFile: false);
	result.ExitCode.ShouldBe(0);
	result.Output.ShouldContain(expectedOutput);
	}

[DarwinJS]

@asbjornu - were you able to reproduce it then?

Are there any examples of verbose output? I'm interested to know if it identifies exactly how it determines the version to use when using verbose output :)

[asbjornu]

It's possible that for the specific code path, there is no difference between Normal and Verbose. You would have to dig into the source code and see whether it logs more than what you can find in your logs. If it does, there's a bug. If it doesn't, you're welcome to add more log statements in a pull requests.

[DarwinJS]

I'm not against pull requests - but this is not a language I know well - let alone knowing the code base.

I am ready to do a pull request for the GitLab documentation because I am building out a GitLab CI CD Extension so that it can be used with any language framework - however, I am baffled at why it is selecting the version number it is when I merge a feature branch to develop. I think a log that shows the algorithm for the specific repository would help with adoption as others would have the same question.

If you are able to take a look at this I am willing to give your GitLab CI docs a major upgrade ;)

[asbjornu]

I agree that having GitVersion output a log that more clearly points out why it has made a decision and its effects on the version number would be highly beneficial. That's not an easy undertaking, however, as it probably requires a complete rearchitecture of the current logging system.

Until such a rearchitecture is implemented, I have to kindly ask you to submit your questions on concrete problems either here or in the discussions area of the repository and I'll do my best to answer.

[DarwinJS]

Apologies - I wasn't making a case for new logging. I was thinking that by fixing this switch whatever exposure of the details of version determination that are already logged would be viewable for learning purposes :)

[asbjornu]

I get it. I'm just not sure the switch is broken or that there are more details to be exposed.