gitversion from container image default behaviour differs from other installation methods

[f2calv]

Hi,

Firstly, love GitVersion, thanks to all contributors :)

Secondly, I've been experimenting with different methods of installing GitVersion in my GitHub workflows and believe I've found an anomaly in the containerised version... or at least something I can't explain, so I hope someone can shed some light here...

I one workflow am runinng 3 parallel jobs, each installing and executing GitVersion via 3 different mechanisms;

• offical gittools actions
• dotnet tool
• container image

Here is the workflow I am executing;
https://github.com/f2calv/playground-gitversion/blob/f2calv/2024-05-checkout-testing/.github/workflows/test.yml

On a simple push trigger everything works as expected, actions/checkout checks out the HEAD;

• https://github.com/f2calv/playground-gitversion/actions/runs/9249843512
  

On a Pull Request trigger the containerised version of GitVersion fails, actions/checkout checks out a MERGE commit;

• https://github.com/f2calv/playground-gitversion/actions/runs/9249843653
  

The initial error is ERROR: fatal: detected dubious ownership in repository at '/repo'. If I then attempt to override the entrypoint in the container by setting safe.directory then GitVersion executes a little further but ultimately fails with Gitversion could not determine which branch to treat as the development branch, I got the safe-directory idea from another issue GitTools/build-images#34.

I would expect all three installation mechanisms of GitVersion to act the same.

Note: If I override the actions/checkout ref with github.event.pull_request.head.sha the containerised version works as expected.

[arturcic]

@f2calv thank you for the detailed description. I will move the issue to the GitVersion repository

[arturcic]

@f2calv do you mind to test with the rc.1 variants of the docker images? The latest tag is using an older version of the image and tool. https://hub.docker.com/r/gittools/gitversion/tags?page=&page_size=&ordering=&name=rc.1.

The latest will be moved to the 6.0 release soon and then the GitTools/build-images#34 will be included

[arturcic]

Additionally on GitHub Actions you need to specify these env vars when executing docker run https://github.com/GitTools/GitVersion/blob/main/build/common/Utilities/DockerContextExtensions.cs#L263-L270

[f2calv]

Thanks @arturcic for the pointers, sorry for delay, I have experimented with;

• ENV vars OR no ENV vars
• tag latest or 6-rc1
• using my (default) GitVersion.yml config file OR no config file

Note: AFAIK this is just a default MainLine configuration file, I use the file mainly as an 'identifier' to let me/others know the repository versioning is managed by GitVersion;

mode: Mainline
branches: {}
ignore:
  sha: []
merge-message-formats: {}

Push request build;

• https://github.com/f2calv/playground-gitversion/actions/runs/9621842304
  • the v6-rc1 job fails with a config file error is 'Mainline' not found, I presume this is a breaking change in v6?

Pull request build;

• https://github.com/f2calv/playground-gitversion/actions/runs/9621842426
  • as above the v6-rc1 job fails with a config file error is 'Mainline' not found, I presume this is a breaking change in v6?
  • latest tag always fails when used without ENV vars
  • strangely the dotnet version fails now, when it worked a some weeks ago?

Conclusions;

• ENV vars are most definitely needed to get success in a PR build (I didn't know this before)
• Config file format is important
• v6 has breaking changes in the config file

Did I miss anything?

[arturcic]

Push request build;

• https://github.com/f2calv/playground-gitversion/actions/runs/9621842304

  • the v6-rc1 job fails with a config file error is 'Mainline' not found, I presume this is a breaking change in v6?

Yes, please check https://github.com/GitTools/GitVersion/blob/main/BREAKING_CHANGES.md#configuration-changes

• strangely the dotnet version fails now, when it worked a some weeks ago?

I checked the log, I suspect you should re-run the job as it seems an GH Actions issue

Conclusions;

• ENV vars are most definitely needed to get success in a PR build (I didn't know this before)
• Config file format is important
• v6 has breaking changes in the config file

Yes, you got it right, I think we need to update the docs on DockerHub and specify the usage when running in a CI environment

[arturcic]

🎉 This issue has been resolved in version 6.0.0-rc.2 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀