GitVersion icon indicating copy to clipboard operation
GitVersion copied to clipboard

[Bug] Default configuration is used when config file specified via -config not found

Open beatcracker opened this issue 4 years ago • 2 comments

Describe the bug

When invalid file name passed to the -config switch (missing file, etc...) no error message is shown and GitVersion silently assumes default configuration.

Expected Behavior

If -config switch is used and specified file not found an error message should be shown.

Actual Behavior

GitVersion silently assumes default configuration. This breaks the principle of least astonishment and makes it hard to debug issues with configuration, especially in CI.

Steps to Reproduce

The GitVersion will generate version using default configuration if the specified config file doesn't exist.

mkdir ./repro
cd ./repro
git init
dotnet tool install --global GitVersion.Tool
dotnet-gitversion -config foobar.xyz

Your Environment

  • Operating System and version: Windows 10
  • GitVesion: 5.7.0+Branch.main.Sha.8d177c6d666c8eeb1c6a6a2c71fd4b78741137d2

I think similar issue related to config file handling was raised already, but unfortunely I can't find it, since config + everything that I was able to come up with are too generic terms for GitHub issue search.

beatcracker avatar Sep 14 '21 23:09 beatcracker

I agree GitVersion should fail, but this can be considered a breaking change and should probably be postponed to v6?

asbjornu avatar Sep 21 '21 07:09 asbjornu

Well, there are probably people out there who rely on this behavior (Hyrum's Law), but I'm not sure if keeping it worth the trouble.

For instance, I'm currently trying to debug why GitVersion refuses to read my config file specified via -config switch and I had to put a GitVersion.yml with garbage inside it into the repo root so GitVersion would actually fail and I could see that my custom config is not being used. And this happens locally. In CI that would be much bigger PITA, since with modern CI systems you can't always repo this on your machine.

So I can think of several improvements/fixes for this:

  • Breaking change: fail if specified config not found
  • Minor change: introduce additional flag that would enable fail behavior.
  • QoL improvement: log full config name to the console output

beatcracker avatar Sep 21 '21 13:09 beatcracker

When invalid file name passed to the -config switch (missing file, etc...) no error message is shown and GitVersion silently assumes default configuration.

I think this statement is confusing a little bit and is not correct: GitVersion always takes the default GitVersion configuration in code. As a user you are able to override this configuration via parameter or defining the configuration file (values will be merged) but the base is still the default configuration in our case the gitflow workflow.

HHobeck avatar Jan 04 '23 16:01 HHobeck

Well, there are probably people out there who rely on this behavior (Hyrum's Law), but I'm not sure if keeping it worth the trouble.

In my opinion it makes no sense to ensure an undocumented feature/behaviour (at least for the next major version) because it was there in the past. Defining a configuration file which is not existing should result in a error for sure.

HHobeck avatar Jan 04 '23 16:01 HHobeck

Sure, but we are also trying to close down the development of v5 to focus on v6. So unless it's very important, such as a security fix or similar, we would prefer to target everything for v6 from now on.

asbjornu avatar Jan 16 '23 14:01 asbjornu

:tada: This issue has been resolved in version 6.0.0-beta.1 :tada: The release is available on:

Your GitReleaseManager bot :package::rocket:

arturcic avatar Mar 02 '23 21:03 arturcic