GitVersionTask 3.6.5 ignoring GitVersion.yml in project dir

[asherber]

I've seen other similar issues. I've got a project with GV 3.6.5 from NuGet. My GitVersion.yml reads:

assembly-informational-format: '{FullSemVer}.{Sha}'
mode: ContinuousDelivery
branches: {}
ignore:
  sha: []

GitVersion /showConfig does correctly show my custom assembly-informational-format, but building the project uses the default {InformationalVersion}.

I have tried deleting the .git/gitversion_cache folder and rebuilding, but no luck.

Any suggestions would be appreciated.

[asbjornu]

@asherber: Are you able to reproduce this in a unit test? A pull request with a failing test would be much appreciated. 😄

[asherber]

I'll see what I can do. FWIW, running GitVersion CLI in my project directory does read GitVersion.yml and shows InformationalVersion with my customizations, but the MSBuild task to stamp my assembly uses the default value. Maybe that will help someone with more familiarity with the codebase track down what's happening.

CLI shows:

{
  "Major":3,
  "Minor":1,
  "Patch":5,
  "PreReleaseTag":"",
  "PreReleaseTagWithDash":"",
  "PreReleaseLabel":"",
  "PreReleaseNumber":"",
  "BuildMetaData":4,
  "BuildMetaDataPadded":"0004",
  "FullBuildMetaData":"4.Branch.master.Sha.cb3156ad0da6352b1e3f7f263ed35df65f4d2553",
  "MajorMinorPatch":"3.1.5",
  "SemVer":"3.1.5",
  "LegacySemVer":"3.1.5",
  "LegacySemVerPadded":"3.1.5",
  "AssemblySemVer":"3.1.5.0",
  "FullSemVer":"3.1.5+4",
  "InformationalVersion":"3.1.5+4.cb3156ad0da6352b1e3f7f263ed35df65f4d2553",
  "BranchName":"master",
  "Sha":"cb3156ad0da6352b1e3f7f263ed35df65f4d2553",
  "NuGetVersionV2":"3.1.5",
  "NuGetVersion":"3.1.5",
  "CommitsSinceVersionSource":4,
  "CommitsSinceVersionSourcePadded":"0004",
  "CommitDate":"2016-12-28"
}

Cache file after NuGet package runs shows:

Major: 3
Minor: 1
Patch: 5
PreReleaseTag: 
PreReleaseTagWithDash: 
PreReleaseLabel: 
PreReleaseNumber: 
BuildMetaData: 4
BuildMetaDataPadded: 0004
FullBuildMetaData: 4.Branch.master.Sha.cb3156ad0da6352b1e3f7f263ed35df65f4d2553
MajorMinorPatch: 3.1.5
SemVer: 3.1.5
LegacySemVer: 3.1.5
LegacySemVerPadded: 3.1.5
AssemblySemVer: 3.1.5.0
FullSemVer: 3.1.5+4
InformationalVersion: 3.1.5+4.Branch.master.Sha.cb3156ad0da6352b1e3f7f263ed35df65f4d2553
BranchName: master
Sha: cb3156ad0da6352b1e3f7f263ed35df65f4d2553
NuGetVersionV2: 3.1.5
NuGetVersion: 3.1.5
CommitsSinceVersionSource: 4
CommitsSinceVersionSourcePadded: 0004
CommitDate: 2016-12-28

Note the difference in InformationalVersion.

[asherber]

Further information. My project setup looks like this:

p:\MySolution
|---TestProject
|---AnotherTestProject

The GitVersionTask NuGet package is installed on TestProject. If GitVersion.yml is located in p:\MySolution, then everything works as expected. But if it is located in the TestProject subdirectory, it gets ignored.

The docs at http://gitversion.readthedocs.io/en/latest/configuration/ say that I should be able to put the config file in any subdirectory, "in case you have a single repository for more than one project".

CLI run from TestProject apparently sees the file sitting right there, but the MSBuild task only wants to look in the solution dir.

[asherber]

Yes, there's definitely something off here. The targets file passes the solution dir into the task; if I build just the project from a command line in the project dir, it passes in $(MSBuildProjectDirectory)\..\, which is the solution dir. I haven't yet gotten a handle on all the code, but it looks like even GitPreparer.GetProjectRootDirectory() is grabbing the parent of the .git dir, which again is the solution dir.

I do see that ConfigurationProvider.Provide() is looking for a config file in the working directory, and that's working for CLI, but in the context of the MSBuild task, the working directory must not be the project directory.

Perhaps this is working as designed, since the repo itself is solution-wide, not specific to the project. But it seems odd for a NuGet package installed at the project level to ignore a config file in the project directory in favor of one in the solution directory. It also means that I can't have different config for different projects within a solution (wanting to set different values for next-version, for example).

[asbjornu]

This sounds related to #1162. Perhaps the same PR can kill both birds?

[JakeGinnivan]

This sentence is confusing...

Once complete, the init command will create a GitVersion.yml file in the working directory. It can be the root repository directory or any subdirectory in case you have a single repository for more than one project or are restricted to commit into a subdirectory.

Pretty sure it's also just wrong. GitVersion.yml is expected to exist in the root of the git repo. In the case of submodules the #1162 should help. Does anyone want to submit a PR to fix the docs?

[asherber]

GitVersion CLI will correctly read a GitVersion.yml in a folder which is not the repo root, so I don't think that sentence in the docs is incorrect. It's just that the behavior of the MSBuild task doesn't match the behavior of the CLI.

[JakeGinnivan]

Ah right. Can you create a new issue which describes the problem clearly. I will close this out and create a new issue which is marked up-for-grabs

[asherber]

#1170 distills the issue.

[JakeGinnivan]

Great thanks @asherber