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)
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.
version.jsonfile that sets the version to
1.2.3-alphaand your stable branch set to
1.2.2(or whatever you most recent stable version was). When your 1.2.3 development branch becomes stable, you remove the
-alphasuffix from the
version.jsonfile for that branch. Does that help?
mainbranch where I'm developing 1.1-alpha, then I may want the
v1.0branch to periodically merge into
mainso that v1.1 will release with all the same fixes that v1.0 had. Nerdbank.GitVersioning works naturally with this because
mainwill have the most recent change to
version.jsonso a merge from
v1.0will not touch version.json, leaving both branches building the version they mean to.
1.2.3-alphabranch merges into a
1.2.3branch. What becomes of the source branch at that point? Does it remain
1.2.3-alphaor does it advance to
1.2.4? And was the target branch
1.2.3before and after the merge?
develop's merge to
mainthat the team of devs working in
developwould have to 'slow down' and not destabilize the branch. The way I and teams around me have done it is work never slows in the primary dev branch, and stabilization happens after branching off, which gives a fine opportunity to change the version.json file. In fact this is so common we have the
nbgv prepare-releasecommand which automates branching off for stabilization that automatically trims the
-prereleasetag on the servicing branch and advances the unstable version from 1.2.3 to 1.2.4 or whatever the policy is that you set in version.config.
develophave conflicting changes for version.json, your gitattributes file could allow git merge to work without conflicts and just leave the copy in the target branch alone.
AfterTargets="GetBuildVersion"attribute, you can review and edit any of the many msbuild properties that NB.GV sets. You could consider the active branch name (
BuildingRef) property and remove the -prerelease tag from the version when the branch being built is
GitVersionBaseDirectoryproperty (or environment variable) to specify where to look for the version.json file. So you could have two version files, in two different directories, and have a github action in your workflow set the
GitVersionBaseDirectoryenv var based on the branch being built to achieve what you want.
pathproperty is documented as a root below the config file, or do I misunderstand the usage and it could be a config file? I'm not using MSBuild, I'm using the github actions workflow and I'm using dotnet publish, see https://github.com/ptr727/PlexCleaner/blob/develop/.github/workflows/BuildPublishPipeline.yml