Nerdbank.GitVersioning: GitBuildVersion not being set when run on self-hosted agent
Today I updated the projects in my solution to NBGV 3.3.37 nuget package from 3.0.48. This was the only change made.
My deployment builds, run on a self-hosted agent, no longer show the ‘pretty’ version in my Azure pipeline history and has reverted to the 20201030.1 format.
More importantly some of my artifacts rely on the GitBuildVersion variable and no longer set. My artifact names now look like product-x86-$(GitBuildVersion).zip instead of product-x86-1.0.22.zip.
The log no longer outputs lines like the following:
2020-10-27T17:34:14.0357436Z ##[section]Async Command Start: Update Build Number
2020-10-27T17:34:14.0358030Z Update build number to 1.0.22 for build 9534
2020-10-27T17:34:14.0358433Z ##[section]Async Command End: Update Build Number
My CI builds, that are run on Azure cloud hosted agents, get their build version updated and artifact names are as expected. Its just when I run the deploy script on the self-hosted agent is when I see the issue.
I checked the doc/cloudbuild.md documentation and did not see any breaking changes from older versions. I build with .NET Framework and do not want to add tasks to install dotnet core just to run the set variables script.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 20
@julealgon two things helped my situation.
Unfortunately to this day, when running CI/CD jobs in Azure DevOps, I have not been able to build the projects in my solutions in parallel and receive output with the expected version information. With that said, though, I am running older NGV versions and have not had the time to try upgrading to see if my issues would be resolved.
I was able determine and fix the issue on my side. Unfortunately, I was unable to reproduce in a slimmed down repo.
I am still trying to get a repo together.
I did use the
/blswitch and msbuildlog.com tool to look at a build where the##vsooutput was missing. The SetCloudVariable related tasks were called as expected with the correct output values. Strange. Too bad the log doesn’t show where the tasks accessed stdout/Console and if issues occurred doing so.