Skip to content

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

@f2calv

Description

@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;

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 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions