[Bug] v6.0.0-beta3 - GitVersion.yml custom master ignored when command line flags passed

[Zordrak]

Describe the bug

Config seems ignored when passing -diag. With a master branch called custom-master, gitversion shows SemVer "1.8.0". gitversion -diag shows SemVer "1.8.0-custom-master.1"

Expected Behavior

"SemVer": "1.8.0"

Actual Behavior

"SemVer": "1.8.0-custom-master.1"

Context

I'm struggling to reliably reproduce it. I was trying to diagnose why I was getting a different result in a custom shell script in GitHub Actions than I was locally, as the github action being invoked with ./gitversion -output file -outputfile gitversion.json -l gitversion.log -nocache; was producing the wrong output, treating the custom-master branch like it was a feature branch. So I tried doing some local diagnostics, and discovered that with -diag mode on, I get the same aberrant behaviour. I can only assume this is something basic to do with passing arguments causing the GitVersion.yml to not be loaded properly?

Your Environment

v6.0.0-beta.3 GNU Linux, Bash 5 x64 binary from GitHub Releases

GitVersion.yml:

---
mode: ContinuousDelivery
branches:  
   master:  
      regex: ^custom-master$
ignore:
  sha: []
merge-message-formats: {}
next-version: '1.0.0'

$ gitversion -output file -outputfile gitversion.json -l gitversion.log -nocache;  grep '"SemVer"' gitversion.json 
  "SemVer": "1.8.0-custom-master.1"

$ gitversion -diag |  grep '"SemVer"'
  "SemVer": "1.8.0-custom-master.1"

$ gitversion | grep '"SemVer"'
  "SemVer": "1.8.0"

This is not the same behaviour as v5.12.0 which acts appropriately, giving 1.8.0 in all cases.

[HHobeck]

Hi @Zordrak.

I'm actually not sure what exactly your scenario is. In beta.3 you have two features:

• unknown branches which can be configured in branches -> unknown
• and fallback branch configuration which can be found on the root configuration level

Please notice that you have specified master branch name not main in your configuration. Thus GitVersion uses label {BranchName} instead of empty label.

Please take a look to the following default base configuration (GitFlow/v1): https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.Configuration/SupportedWorkflows/GitFlow/v1.yml

Good to know: You can change the base configuration by specifying the workflow property on root level. Empty means no base configuration.

[Zordrak]

I think you may have missed the point of the bug.

The behaviour is changed by the passing of command line flags.

gitversion and gitversion -diag and gitversion -output file -outputfile gitversion.json should produce the same SemVer regardless of the configuration.

[HHobeck]

Hi. I have taken your example and have verified it that it is working and the bug is not reproduceable. Can you please provide steps to reproduce?

Thank you!

Edit: Like I mentioned master is not known anymore in GitVersion configuration

[HHobeck]

This is not the same behaviour as v5.12.0 which acts appropriately, giving 1.8.0 in all cases.

Giving the result of 1.8.0-custom-master.1 back is fully correct in your case why do you expecting 1.8.0? Or do I miss something!?

[HHobeck]

[Zordrak]

I am doing what I can to create completely generic reproduction steps, but it's difficult to know exactly where it's happening in the release repo I'm currently working on.

I thought that it was just an artifact of the change from acknowledging master to not acknowledging master, and maybe some code was still accounting for master by mistake.. but with GitVersion now pointing main at the custom branch I'm still getting a difference in 6b3 that isnt in 5.12.

GitVersion.yml

---
mode: ContinuousDelivery
branches:
  main:        
    regex: ^custom-master$
  develop:  
    regex: ^custom-develop$
ignore:
  sha: []
merge-message-formats: {}
next-version: '1.0.0'

On branch custom-master with HEAD~1 tagged with both v1.9.0-beta.1 & tag: v1.9.0-alpha.1

6b3 with -diag flag: 1.9.0-1

$ ../gitversion-6.0.0-beta.3 -diag | grep \"SemVer\"
  "SemVer": "1.9.0-1",

6b3 without flags: 1.9.0

$ ../gitversion-6.0.0-beta.3 | grep \"SemVer\"
  "SemVer": "1.9.0",

5.12 with -diag flag: 1.9.0

$ ../gitversion-5.12.0 -diag | grep \"SemVer\"
  "SemVer": "1.9.0",

5.12 without flags: 1.9.0

$ ../gitversion-5.12.0 | grep \"SemVer\"
  "SemVer": "1.9.0",

I will let you know when I get a generic reproducable, which might have to wait until I'm done with the feature I'm delivering, but there's definitely something shonky going on when 6.0.0-beta.3 is passed command line arguments.

[Zordrak]

The results I see are the difference between any flags being passed and no flags being passed. I am using -diag as the simplest example, but both of your outputs there are passing -nocache which would mean I would expect both outputs to be the same. Try passing no flags at all.

[HHobeck]

The results I see are the difference between any flags being passed and no flags being passed. I am using -diag as the simplest example, but both of your outputs there are passing -nocache which would mean I would expect both outputs to be the same. Try passing no flags at all.

Here is the output when not passing any flags:

BTW: Also if I'm emptying the git version cache (delete the folder in .git\gitversion_cache\) I still get the above result.

[github-actions[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.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity. Thank you for your contributions