Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 05 07:29
    KalleOlaviNiemitalo commented #828
  • Oct 05 07:28
    KalleOlaviNiemitalo commented #828
  • Oct 04 07:20
    KalleOlaviNiemitalo commented #827
  • Oct 04 07:16
    KalleOlaviNiemitalo commented #827
  • Oct 02 04:17

    dependabot[bot] on main

    Bump xunit.runner.visualstudio … (compare)

  • Oct 02 04:17
    dependabot[bot] closed #831
  • Oct 02 04:17

    dependabot[bot] on nuget

    (compare)

  • Oct 02 03:51
    dependabot[bot] synchronize #831
  • Oct 02 03:51

    dependabot[bot] on nuget

    Bump xunit.runner.visualstudio … (compare)

  • Oct 02 03:51
    dependabot[bot] edited #831
  • Oct 02 03:51
    dependabot[bot] edited #831
  • Oct 02 03:50

    dependabot[bot] on main

    Bump xunit from 2.4.1 to 2.4.2 … (compare)

  • Oct 02 03:50

    dependabot[bot] on nuget

    (compare)

  • Oct 02 03:50
    dependabot[bot] closed #832
  • Oct 02 03:49

    AArnott on dropnet461

    (compare)

  • Oct 02 03:49

    AArnott on main

    Drop support for .NET Framework… Merge pull request #836 from do… (compare)

  • Oct 02 03:49
    AArnott closed #836
  • Oct 02 03:33
    dependabot[bot] edited #819
  • Oct 02 03:33
    dependabot[bot] synchronize #819
  • Oct 02 03:33
    dependabot[bot] edited #819
Robert Dailey
@rcdailey
I'll do better I'll open a PR. And yes I agree with your solution. I assumed some people may not want the 4th number even if they use 3 instead of 2 components in version.json. But I like keeping things simple
Robert Dailey
@rcdailey

@AArnott Are you sure it's the first 15 bits of the SHA1? With this, I still get what appears to be {height} as the fourth component:

{
    "version": "7.4.2",
    "publicReleaseRefSpec": [
        "^refs/tags/v\\d+\\.\\d+",
        "^refs/heads/master$"
      ],
    "assemblyVersion":{
        "precision": "minor"
    },
    "nugetPackageVersion": {
        "semVer": 2
    },
    "release": {
        "branchName": "release/v{version}",
        "versionIncrement": "minor",
        "firstUnstableTag": "alpha"
    },
    "cloudBuild": {
        "setVersionVariables": true,
        "buildNumber": {
            "enabled": true,
            "includeCommitId": {
                "when": "always",
                "where": "fourthVersionComponent"
            }
        }
    }
}

Of note here is "where": "fourthVersionComponent", which I expect to be a number greater than 4 (for the fourth component):

$ nbgv get-version -f json
{
  "CloudBuildNumber": "7.4.2.4",
  "CloudBuildNumberEnabled": true,
  "BuildMetadataWithCommitId": [
    "1377ba7113"
  ],
...

Ran this locally on commit:

$ git rev-parse @
1377ba71133198af1bc0b9e91e0b284e5cc09c05

I expect 1377 (first 15 bits) to be 100110111011 which should be decimal 2491. Where am I wrong?

Andrew Arnott
@AArnott
@rcdailey Your version.json file specifies 3 integers for version, which pushes the version height component to the 4th position, leaving no room for the commit ID to be represented in any of them. You'll only get this 15-bits of SHA1 behavior when you specify the recommended two integers for version instead of 3.
I guess though that maybe we should error out when you specify fourthVersionComponent in conflict with the need to put some other number in that position.
Robert Dailey
@rcdailey
fourth is an absolute position, not a relative one. Perhaps a less confusing name would be relativeToHeightComponent
Robert Dailey
@rcdailey
I should also note that fourthVersionComponent changes the behavior of the fourth component even if it isn't showing the commit hash. It forces it to use the four component number fully in the Azure Pipelines build name, for example.
I think there's a confusing mixture of concerns with this setting that isn't really obvious, and certainly not documented.
Robert Dailey
@rcdailey
@AArnott Any possibility in getting my pull request reviewed? Trying to get it in for use at my day job.
Andrew Arnott
@AArnott
yes... I've just been extremely busy so I'm not sure how soon I'll get to it. How is it blocking you? That setting only influences the cloud build number, which isn't typically required to be in a particular format. Is it different for you?
Robert Dailey
@rcdailey
Sorry I didn't mean to imply I was blocked. It's just something "they really want", so I wanted to tug your sleeve about it. If you're busy I totally understand. Thank you for putting up with my pestering :)
Robert Dailey
@rcdailey

Is it possible to make NBGV apply a prerelease tag to a version number if we're not on a public release refspec? Docs say that this functionality is not possible; it only controls the -123abc hash at the end. But I'd like my version to be 1.1-dev if it's not a public release; and 1.1 if it is. Without changing my version.json.

Being able to set it up like this would be nice:

  "version": "1.6.1",
  "prereleaseTag": "dev",
  "publicReleaseRefSpec": [
    "^refs/tags/v\\d+\\.\\d+"
  ],

For even more context: I do not use prepare-release. I use continuous delivery. I ship directly on master but my CI pipeline only publishes builds that are tagged. I also only change my version number after a release. So the first release will be, for example, v1.1 and builds after that are v1.1-dev until the next release, v1.2. At least, that's what I want it to do...

Andrew Arnott
@AArnott
@rcdailey no, at present the philosophy is that stability is a characteristic of a git commit rather than a branch it may belong to. A commit may belong to any number of branches, and that set can even change over time. But the commit itself is either deemed stable or unstable, so a version.json change is required to lock in what the developer deems to be either one.
That said, I have heard this request a few times, so we might offer that feature sometime in the future.
Robert Dailey
@rcdailey

Does NBGV offer any automation as far as propagating version numbers to nuget pack command, and filling it in the nuspec file? For example do I need to do this:

nuget pack MyProject.nuspec -p "version=$NBGV_NuGetPackageVersion;configuration=Release"

Or is there room to simplify?

Andrew Arnott
@AArnott
@rcdailey First question is why you pack that way. If you have a self-packing csproj you can still specify a nuspec file (if you really need to) and you can specify nuspec properties too like I do here: https://github.com/dotnet/Nerdbank.GitVersioning/blob/4449325df1896ff7f5e9f94705ce194669afaafa/src/Nerdbank.GitVersioning.Tasks/Nerdbank.GitVersioning.Tasks.csproj#L19-L25
Then you can just use dotnet pack or msbuild /t:pack on your project file and the version info propagates automatically.
Robert Dailey
@rcdailey
For specifically Azure Pipelines (VisualStudioTeamServices), how often should nbgv cloud be invoked? Once per job? Once in the root YAML, no matter how many stages or jobs it has? If it only defines the Azure Pipelines build variables, what is the "scope" of that? I assumed it needed to be run once per job, since each of those may run on its own unique agent. Is it not environment dependent? I'm running once per job right now but I'm not sure if that's wasteful and, worst case, potentially destructive if it's overwriting previous state when a new job starts.
Andrew Arnott
@AArnott
@rcdailey the cloud build number is assigned to the overall pipeline, so setting it multiple times is just redundant. But if setting the pipeline variables are what you're after then once per job that requires them is appropriate. Just know that each job you run it for will need the same checkout operation.
nrpatil1993
@nrpatil1993
@AArnott
I need to implement something like this, we have 2 branches, one master and one release. Both master and release can have pre-release versions. The pre-release version should be like major.minor.patch-pre{timestamp}, e.g. 3.8.1-pre10222021. We don't want the git commit Id as suffix for the version. I'm trying to understand how to implement this from last 4 days. What should be the version.json for this?
Andrew Arnott
@AArnott
@nrpatil1993 The commit ID is only added as a suffix for the version for non-public releases, as specified in the version.json file. As you'll be releasing both from master and a release branch, you'll want both of these to match the regex(es) in publicReleaseRefSpec of your version.json file. Note that there should only ever be one public release branch per version number (so that they don't overlap across branches).
As for your -pre10222021 suffix, you could specify that in your version.json file, but nothing you can configure will persuade that date-looking suffix to be generated automatically, as nbgv is strictly deterministic rather than calendar-based. But you can do that if you want by using nbgv to generate most of the version information and then with some msbuild Target you can modify the generated version properties after the GetBuildVersion target runs in order to append or change whatever you want to the computed version.
nrpatil1993
@nrpatil1993

@AArnott
Ok, few doubts here. I'm referring to this schema here (https://raw.githubusercontent.com/AArnott/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json).

What is the use of include commit id, if publicReleaseRefSpec will decide if commit id should be added or not?

"cloudBuild": {
"setVersionVariables": true,
"buildNumber": {
"enabled": true,
"includeCommitId": {
"when": "never"
}
}
}

Andrew Arnott
@AArnott
@nrpatil1993 The cloudbuild.buildNumber.includeCommitId has nothing to do with the version that is included in the built binaries. It only influences whether the commit ID is included in the build number as represented in your cloud build system.
The publicReleaseRefSpec influences whether the commit ID is appended to built NuGet/NPM packages.
Will 保哥
@doggy8088
I tried MSBuild with /p:publicrelease=true property. The output assembly (*.dll) still shown 1.0.101+22f36f. How can I strip +22f36f part in the output assembly?
Will 保哥
@doggy8088
image.png
Will 保哥
@doggy8088
It seems AssemblyInformationalVersion always have a Commit ID in it.
Andrew Arnott
@AArnott
Yes, the assembly informational version always retains the commit ID. This is a free-form string and the commit ID fits nicely into it for precise lookup back to the source code. It has no impact on the version that the CLR or Windows sees.
Robert Dailey
@rcdailey
I'm not seeing an easy built in way to tell nbgv cloud to use the InformationalVersion for the build title/name. Would this be a reasonable thing to PR? Right now the workaround I'm trying is to manually do Write-Host to overwrite the ##vso variable after I invoke nbgv cloud, but it's difficult to get working and I have to scatter it across several YAML files. This is for VSTS (Azure Pipelines).
Andrew Arnott
@AArnott
nbgv cloud sets the build number to something very similar (if not identical to) the informational version, IIRC. What variance are you seeing, @rcdailey, and (perhaps) why is that variance significant to you?
Nigel Whatling
@NigelWhatling
I'm using path filters (["."]) to manage versions on a number of projects in a mono repo. In this case the development branch is the "release" branch and feature branches are pre-release. Existing projects (a number initially created at the same time) versions seem to work as expected. A merge back into development branch creates a release version. I increment the version for new work after that (e.g. 1.1) and the height is calculated for that project based on height since last merge.
However, if I add a new project with same settings, its initial height is calculated at what I assume is the height from very first commit with NB. For example, first commit of brand new project might result in version 1.0.84-####. I would have expected that the height would be calculated based on the path filter (subtree only). In other words, since the subtree and version.json file in question has only existed in the repo for exact one commit, the version should be 1.0.1-####.
Am I missing something?
Andrew Arnott
@AArnott
@NigelWhatling When NB.GV computes the version height, it considers the path to the project whose version is being calculated, at each commit going back in history, so long as the version field of the version.json file has not changed. The commit that introduces a path filter may not be the first commit to set the version. If for example you have a root-level version.json file that sets the version to 1.0, and then you add a new version.json file in a subdir, with a path filter, that also sets (or inherits) the 1.0 version, then you haven't changed the version, and the git history traversal will honor the path filter for those commits that define the path filter, and when it encounters a commit without a path filter (or with a different set of filters), it will honor that for those commits.
If all you ever had were subdirs with version.json in each one, and never one in a parent dir of a new dir you created, then I think you could expect a version height starting at 0 (or 1, practically speaking).
BTW: You can force a 'reset' using the versionHeightOffset property, by setting it to a negative value.
Nigel Whatling
@NigelWhatling
@AArnott Hmm. I do have a version.json file in a parent directory with version 1.0. I didn't think that would be an issue because the project level file overrides the version (with same version in this case) and uses the pathFilter. But it sounds like the parent file is causing the problem. Not sure how I get around that by without some nasty git hacking. 🤔
Thanks for the response. 👍
Andrew Arnott
@AArnott
@NigelWhatling Yes, the new project level file overrides it -- when introduced. But in that commit's parent, it wasn't there to override and yet the version is the same so the height continues to grow.
Do you need the parent-level file? If not, you can remove it. Then, after at least one commit with it gone, a new subdir created with a version.json file will have a version height of 1.
One reason for this is that versions going backwards is generally a bad thing. So if your existing project in git has version 1.0.500, and you decide you want to add path filters to it and do so by adding a version.json file to that directory, that shouldn't make the height go backwards to 1, right? You'd simply want it to continue at 1.0.501 but increment less frequently going forward.
Nigel Whatling
@NigelWhatling
@AArnott I think my issue was with how I was looking at the pathFilters setting. Setting it as I have filters away changes, but doesn't change the fact that the version files still inherit up (because I have set them to).
I want to keep the parent-level version file because that is where I have common settings for all of the projects (although, admittedly, there aren't a huge number of those). The only thing that is set in the project-level files is the version for that project (and pathFilters).
Anyhoo... After a bit of git hacking, I eventually updated the parent version.json file to version 0.0 and rebased my project branch. This has done the trick. New build spits out as 1.0.1. 👍
Egil Hansen
@egilhansen:matrix.org
[m]
hey @AArnott I have a solution wide version.json, but want to have different rules for a sub project (currently fixed as a preview release). What is the best practice for that?
Egil Hansen
@egilhansen:matrix.org
[m]
I would like the preview lib to follow the same versions as the other libs in the same repo, but it should just always have the "preview" version prefix, even when build in release mode/non-prevew mode.
Right now I am using nbgv prepare-release to create releases/bump release versions.
Andrew Arnott
@AArnott
@egilhansen:matrix.org I would normally prescribe multiple version.json files where the sub-level ones use "inherit": true and then set only what they want to override. nbgv prepare-release only updates one version.json file (the one you point it at), so if you have sub-level global.json files that set "version": "1.2-preview" then they will remain in preview even while the root level one drops its -preview suffix.
Will that suit you?
Egil Hansen
@egilhansen:matrix.org
[m]
@AArnott: maybe. if I add a version.json inside the "preview project" folder, and set inherits to true, what other options should I add the preview projects version.json to have it always apply the -preview suffix to the verison, even when the parent version.json doesnt have that suffix in its version, i.e. because it has been removed after running nbgv prepare-release.
Andrew Arnott
@AArnott
The preview folder's version.json will need to set the entire version (e.g. 1.2-preview). Are you saying that nbgv prepare-release is removing the -preview suffix even from the subfolder? (hint: you should be running that tool from the directory containing the root file, or specifying the path explicitly).
nrpatil1993
@nrpatil1993
image.png
nrpatil1993
@nrpatil1993

@AArnott
How to modify the generated version properties using some msbuild target? We are using the Nuget package, and don't have to do much, we just do these steps in our CI pipeline => VS Build => Nuget Push => Publish => Publish Build Artifacts

Do I need to modify the version properties in the pipeline or is it from our c# code somehow?

Andrew Arnott
@AArnott

@nrpatil1993 No C# or pipeline changes should be required. It's an msbuild target, so you could for example add a Directory.Build.targets file to the root of your repo with content like this:

<Project>
  <Target Name="TinkerWithVersionProperties" AfterTargets="GetBuildVersion">
    <PropertyGroup>
      <NuGetPackageVersion>$(NuGetPackageVersion)-abc</NuGetPackageVersion> 
    </PropertyGroup>
  </Target>
</Project>

That would effectively forcibly add -abc to the end of every nuget package. Now there are better ways to do that particular thing, but the point is you can take the msbuild properties that nb.gv sets and tailor them to your exact needs.
You can see the full list of properties that nb.gv sets in msbuild here.

nrpatil1993
@nrpatil1993

@AArnott
Ok. Did the changes. Have added this file in the same folder where the .csproj exist.

<?xml version="1.0" encoding="utf-8"?>
<Project>  
  <Target Name="TinkerWithVersionProperties" AfterTargets="GetBuildVersionCore"> // or GetBuildVersion
    <PropertyGroup Condition="$(NuGetPackageVersion.EndsWith('$(GitCommitIdShort)'))">
      <NuGetPackageVersion>$(MajorMinorVersion).$(GitVersionHeight)-pre$([System.DateTime]::UtcNow.ToString(yyyyMMddHHmmss))</NuGetPackageVersion>
    </PropertyGroup>
  </Target>

  <Target Name="AdjustVersion" AfterTargets="GetBuildVersionCore"> // or GetBuildVersion
    <PropertyGroup>
      <AssemblyInformationalVersion>$(NuGetPackageVersion)</AssemblyInformationalVersion>
    </PropertyGroup>
  </Target>
</Project>

With this change, when I build the code locally, it is adding Product version with the required version. But when I push it and run the CI pipeline, it still goes with the regular version having git-commit Id in it, and it is not getting updated.

Am I doing anything incorrect here?

dll_properties.png
Andrew Arnott
@AArnott
@nrpatil1993 Did you perhaps forget to dad the new file to git so that the file would appear on the CI machine?
Another way to investigate this is build (on CI) using the -bl switch to msbuild or dotnet build and collect the resulting msbuild.binlog file as an artifact. Then open that file using the tool at https://msbuildlog.com and see whether your target runs and what (else) happens to those properties that you're setting.
Julien Chomarat
@juchom

Hello,

I have a strange issue, I cannot solve. How can I disable NBGV from a project ?
I tried removing the whole PackageReference from Directory.Build.props and I still see the NBGV task when I do a dotnet build...

Julien Chomarat
@juchom
I tried clearing the nuget cache and I saw that this files were locked by some dotnet.exe processess
nerdbank.gitversioning\3.4.244\build\MSBuildCore\LibGit2Sharp.dll
nerdbank.gitversioning\3.4.244\build\MSBuildCore\NerdBank.GitVersioning.dll
nerdbank.gitversioning\3.4.244\build\MSBuildCore\Nerdbank.GitVersioning.Tasks.dll
nerdbank.gitversioning\3.4.244\build\MSBuildCore\Newtonsoft.Json.dll
nerdbank.gitversioning\3.4.244\build\MSBuildCore\Validation.dll
Andrew Arnott
@AArnott
@juchom I can only speculate that you have another PackageReference somewhere or you haven't done a nuget package restore since removing the last one.
Julien Chomarat
@juchom
Now, it works fine...