AArnott on main
Update doc links Force non-shallow clones Fixes… Switch to using dotnet-coverage… and 6 more (compare)
AArnott on libtemplate
AArnott on libtemplate
Update doc links Force non-shallow clones Fixes… Switch to using dotnet-coverage… and 5 more (compare)
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
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...
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?
msbuild /t:packon your project file and the version info propagates automatically.
nbgv cloudbe 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.
publicReleaseRefSpecof 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).
-pre10222021suffix, 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
GetBuildVersiontarget runs in order to append or change whatever you want to the computed version.
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.buildNumber.includeCommitIdhas 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.
publicReleaseRefSpecinfluences whether the commit ID is appended to built NuGet/NPM packages.
nbgv cloudto 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-Hostto overwrite the
##vsovariable 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).
["."]) 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.
versionfield 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.
versionHeightOffsetproperty, by setting it to a negative value.
nbgv prepare-releaseto create releases/bump release versions.
"inherit": trueand then set only what they want to override.
nbgv prepare-releaseonly 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
-previewsuffix 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
1.2-preview). Are you saying that
nbgv prepare-releaseis removing the
-previewsuffix even from the subfolder? (hint: you should be running that tool from the directory containing the root file, or specifying the path explicitly).
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?
@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.
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?
-blswitch to msbuild or
dotnet buildand 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.
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
Is it a bug that NBGV uses the new version number from an uncommited version.json but ignores changes to the prerelease-tag?
In an uncommited version.json I can change the version number and nbgv get-version will print the new version directly, without commiting. Changes to the prerelease -tag are completely ignored until I commit the changes.