Nuget Package Version and nbgv cloud NBGV_NuGetPackageVersion differ

[epvanhouten]

Nerdbank.GitVersioning Version 3.1.68

version.json

{
    "$schema": "https://raw.githubusercontent.com/dotnet/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json",
    "version": "0.2",
    "pathFilters": ["."],
    "publicReleaseRefSpec": [
        "^refs/heads/master$"
      ]
  }

Results in package like <Package Name>.0.2.0-g49454ca976.nupkg and NBGV_NuGetPackageVersion like 0.2.1-g49454ca976.

[AArnott]

Can you include a diagnostic build log? (/bl switch and the .binlog file would be great)

[epvanhouten]

nerdbankDebug.zip

Produced by running

dotnet pack /bl
nbgv cloud -s VisualStudioTeamServices --all-vars > AzDoAllvars.txt

in this repo.

[AArnott]

Thanks for the great repro. I can repro it as well and am investigating. It appears to be specific to @saul's new pathFilters feature that you're using.
Any ideas, @saul?

[AArnott]

BTW, the difference isn't in the package vs. the CLI. The difference is whether the version calculation is from the repo root or the project directory.
So @epvanhouten, a workaround for you would be to pass the -p sub-dir argument when calling nbgv so that the relative path is the same as the path that contains the project being packed.

[epvanhouten]

That may be reasonable behavior. If you’re using it to generate multiple package versions don’t know how else you would deal with it.

…

Sent from my iPhone

On Mar 14, 2020, at 11:46, Andrew Arnott ***@***.***> wrote:  BTW, the difference isn't in the package vs. the CLI. The difference is whether the version calculation is from the repo root or the project directory. So @epvanhouten, a workaround for you would be to pass the -p sub-dir argument when calling nbgv so that the relative path is the same as the path that contains the project being packed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[AArnott]

Well, since version.json was defined only once in the root, and the pathfilter indicated ., that I would expect to mean all files and directories at the repo root and below. So I expect the same version throughout.

[epvanhouten]

Sorry I was thinking in the model of having multiple version.json files. Yes nbgv cloud on any directory under a version.json should be consistent with the packages produced by those projects. But if you have multiple version.json files running around you’re going to need to tell nbgv cloud, by cding or passing the path, the correct sub tree to calculate a version for. This is probably an obvious clarification, but more for my own benefit.

…

Sent from my iPhone

On Mar 14, 2020, at 13:26, Andrew Arnott ***@***.***> wrote:  Well, since version.json was defined only once in the root, and the pathfilter indicated ., that I would expect to mean all files and directories at the repo root and below. So I expect the same version throughout. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmezach]

I'm seeing a similar issue, but even after removing the path filters it doesn't seem to work. I'm using GitHub Actions and I see that my NuGet package I'm producing gets a different version number then when I try to restore that same NuGet package later on in a different job.

For some reason the NuGet package version being calculated is two Git commits higher than what's being set by nbgv cloud. Interestingly running nbgv cloud locally on my development machine produces the correct version number. This is kinda driving me crazy.

Feel free to have a look at my repo. For example, in this CI Workflow I'm seeing that nbgv cloud --all-vars sets NBGV_NuGetPackageVersion to 1.0.0-beta.23, but later on in that same job when I do a dotnet pack I'm getting 1.0.0-beta.25 as the version number.

[jmezach]

Applying @AArnott's workaround of specifying the sub path explicitly when running nbgv cloud seems to resolve my issue. Still don't understand why that's necessary though because I only have one single version.json file in my entire repository.

[AArnott]

I'm glad the workaround worked, @jmezach.
There's no good reason for it -- it's just a bug in the pathFilter feature. This is exactly why I was hesitant to accept that PR: I figured there was a high chance it would be buggy. So far I haven't heard from @saul who contributed it and if I don't have time to investigate fixing it myself and no one else contributes I may remove the feature.

[AArnott]

even after removing the path filters it doesn't seem to work

Probably because you didn't rewrite your past commits. NB.GV is a git history based algorithm so if your pathFilter is in any of your git commit history, it will still impact the version height calculation even if your more recent commits no longer use it.

[saul]

For what it's worth, we've been using path filters on dozens of packages at our company with no issues. Although from the comments in this ticket, it appears this issue is only happening with NBGV cloud? I could certainly set aside some time to dig into this.

[AArnott]

Thanks, @saul!

A bit more info to help you:
The problem is not with nbgv cloud it has to do with the directory the version is calculated for. As people typically run nbgv cloud, the context is usually the repo root directory. Since the version calculated for any project is the project directory, these two directories are different and the version is different due to the bug. The workaround I prescribe above demonstrates how nbgv cloud -p some-project-dir demonstrates this.

Here are the pathFilters used in the two folks who have reported version mismatches:

rr-wfm/MSBuild.Sdk.SqlProj@9cbba15
https://github.com/epvanhouten/nerdbankReproduction/blob/1bc6de56915bd868503e91274d471bd249f08dd0/version.json#L4

[AArnott]

Any progress, @saul?

[saul]

Hi - I did spend a couple of hours on Friday afternoon looking into this but it wasn't immediately obvious how I could fix it. I'm setting aside more time tomorrow in the working day to dig deeper.

Is there an easier way to communicate with you both instead of GitHub comments? I may have some more questions re the cloud functionality.

Thanks

[AArnott]

Yes: you can find me on gitter.im. this repo has a room there.

But again, this has nothing to do with the cloud feature, and everything to do with the "projectDirectory" used to start the version calculation.

[saul]

OK so my understanding of the problem is that when building a project, repoRelativeProjectDirectory is the path to the directory that the csproj/fsproj lives in. When running nbgv cloud, repoRelativeProjectDirectory points to the root of the repo. This is causing version differences when relative paths are used.

I believe the bug here is that relative paths should always be relative to the version.json file, not the project directory. I'll see if I can whip up a unit test to exercise this.

[saul]

Opened #465 which fixes this