search

GitTools / GitVersion

From git log to SemVer in no time
https://gitversion.net/docs/
MIT License
2.83k stars 648 forks source link

gitversion from container image default behaviour differs from other installation methods #4042

Closed f2calv closed 2 months ago

f2calv commented 3 months ago

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;

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;

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

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 https://github.com/GitTools/build-images/issues/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 commented 3 months ago

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

arturcic commented 3 months ago

@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 https://github.com/GitTools/build-images/issues/34 will be included

arturcic commented 3 months ago

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 commented 2 months ago

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

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;

Pull request build;

Conclusions;

Did I miss anything?

arturcic commented 2 months ago

Push request build;

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 commented 2 months ago

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

Your GitReleaseManager bot :package::rocket: