[Bug] GitVersion.MsBuild does not respect the GitVersionPath or GitVersionUseSolutionDir properties

[vgriph]

Describe the bug When migrating from GitVersionTask to GitVersion.MsBuild it is no longer possible to have a git version configuration per solution in a repository containing multiple solutions.

We have a repository containing two solutions in two different directories at the repository root. Each solution contain a few projects that all should have the same version. We have placed a GitVersion.yml config file at the top of each solution directory, and used to reference GitVersionTask from Directory.buid.props, and also set the GitVersionUseSolutionDir property from there.

When replacing GitVersionTask with GitVersion.MsBuild, we would need to put GitVersion.yml files in each project directory, or disable the RunGitVersionTask and call gitversion ourselves specifying the solution directory.

Expected Behavior

It should be possible to use configuration either repository-wide, solution-wide or project wide. Ideally, the detection should be automatic, and thee should be no need to specify any properties, but in lack of that, the properties that were respected by GitVersionTask should still function when migrating to GitVersion.MsBuild to make the migration step smooth.

Actual Behavior

GitVersion.MsBuild calls gitversion specifying the project directory as the working directory, the is no GitVersion.yml file in that folder, nor in the working directory root folder, so gitversion uses the default config and generates some version.

Possible Fix

One way to make it automatic is to make gitversion look for a config file, no only in the working directory and the repository root, but also in each parent directory from the working directory to the repository root, and take the first config file it finds. This fix would solve our usecase without having to specify any properties, and would be working the same when using the command line and the msbuild task.

However, it could possible be a breaking change if someone depended on the repository root config file being used when the working directory is missing a config file, and that someone also had some GitVersion.yml in between the working directroy and the repository root. It would also not fix the issue if someone have specified a different GitVersionDirectory which is not between the repository root and the project directory, using the GitVersionPath property.

Steps to Reproduce

The file contains a sequence of bash commands that can be used to reproduce the behaviour. GitVersionUseSolutionDir-reproduction-steps.txt

In words: Create a git repository with two solutions, each with two projects. Initialize gitversion with different configs for the different project files Create a top-level Directory.build.props referencing GitVersion.MsBuild and specifying the property <GitVersionUseSolutionDir>True</GitVersionUseSolutionDir>

<Project>
  <PropertyGroup>
   <GitVersionUseSolutionDir>True</GitVersionUseSolutionDir>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="GitVersion.MsBuild" Version="5.8.2" />
  </ItemGroup>
</Project>

Pack the two solutions. Look at the version number of the generated nuget packages.

When referencing the GitVersion.MsBuild 5.8.2 package, all packages built are version 0.1.0 If replacing GitVersion.MsBuild 5.8.2 with GitVersionTask 5.5.1, the packages will instead have versions based on the GitVersion config for each solution.

Context

This bug prevents me from migrating from GitVersionTask to GitVersion.MsBuild without additional changes to the code base.

Your Environment

• Version Used: 5.8.2
• Operating System and version: Windows 10, version 1909
• GNU bash 4.4.23
• dotnet 6.0.102

[asbjornu]

One way to make it automatic is to make gitversion look for a config file, no only in the working directory and the repository root, but also in each parent directory from the working directory to the repository root, and take the first config file it finds.

I think this sounds like a fine solution. It may be seen as a breaking change, though. Thoughts?

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

[fowl2]

One way to make it automatic is to make gitversion look for a config file, no only in the working directory and the repository root, but also in each parent directory from the working directory to the repository root, and take the first config file it finds.

I think this sounds like a fine solution. It may be seen as a breaking change, though. Thoughts?

I think any preexisting intermediate configuration files are likely to be a mistake. Any existing MSBuild GitVersionPath and/or GitVersionUseSolutionDir properties are in the same boat, but I think adding properties is typically considered non-breaking, if a prefix (ie. GitVersion) is used. The fact that they previously existed by muddy the waters here, but I think making any existing docs/answers that reference them work again outweighs that chance.

TL;DR: I don't think a major version bump is necessary for adding either/both solution.

[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