CI fails intermittently in the dotnet pack step, on both ubuntu-latest and windows-latest, with:
##[error]Unable to process file command 'env' successfully.
##[error]Invalid format '.15.0'
The fragment varies — I have seen .15.0 and b44c3c (part of a commit SHA). The pack itself succeeds; every package is created. The failure is the runner parsing $GITHUB_ENV after the step.
Cause
Nerdbank.GitVersioning's SetCloudBuildVersionVars target runs AfterTargets="GetBuildVersion", i.e. once per project, and each invocation appends to $GITHUB_ENV. dotnet pack builds projects in parallel, so those appends interleave and a line gets split mid-value. GitBuildVersion=0.15.0 torn in two yields exactly Invalid format '.15.0'.
Reproduced locally by pointing GITHUB_ENV at a file:
GITHUB_ACTIONS=true GITHUB_ENV=/tmp/ghenv.txt CI=true dotnet pack wham.sln
wc -l < /tmp/ghenv.txt # 108 lines, 3 distinct variables written ~36 times
Only 3 distinct variables are involved (GitBuildVersion, GitBuildVersionSimple, GitAssemblyInformationalVersion) — the rest is redundant repetition, which is the race surface.
This got worse with the roster-engine stack: the solution went from 18 to 31 projects, so there are far more concurrent writers. That matches it hitting several stack PRs while rarely affecting main before.
Things that do not fix it
Nerdbank.GitVersioning 3.10.91 (verified — still writes 108 lines)cloudBuild.setVersionVariables: false in version.json (verified — that governs the nbgv cloud CLI, not the MSBuild target)
Options
- Override the target to a no-op in
Directory.Build.targets. No workflow consumes these variables — ci.yml, publish.yml and tag-command.yml all shell out to dotnet nbgv get-version instead — so nothing should break, but it does skip nbgv's MSBuildPropertyUpdates output.
- Run the pack step with
-m:1. Correct but slower.
- Report upstream to Nerdbank.GitVersioning as a concurrency bug.
Workaround today: re-run the failed job.
CI fails intermittently in the
dotnet packstep, on bothubuntu-latestandwindows-latest, with:The fragment varies — I have seen
.15.0andb44c3c(part of a commit SHA). The pack itself succeeds; every package is created. The failure is the runner parsing$GITHUB_ENVafter the step.Cause
Nerdbank.GitVersioning's
SetCloudBuildVersionVarstarget runsAfterTargets="GetBuildVersion", i.e. once per project, and each invocation appends to$GITHUB_ENV.dotnet packbuilds projects in parallel, so those appends interleave and a line gets split mid-value.GitBuildVersion=0.15.0torn in two yields exactlyInvalid format '.15.0'.Reproduced locally by pointing
GITHUB_ENVat a file:Only 3 distinct variables are involved (
GitBuildVersion,GitBuildVersionSimple,GitAssemblyInformationalVersion) — the rest is redundant repetition, which is the race surface.This got worse with the roster-engine stack: the solution went from 18 to 31 projects, so there are far more concurrent writers. That matches it hitting several stack PRs while rarely affecting
mainbefore.Things that do not fix it
Nerdbank.GitVersioning3.10.91 (verified — still writes 108 lines)cloudBuild.setVersionVariables: falseinversion.json(verified — that governs thenbgv cloudCLI, not the MSBuild target)Options
Directory.Build.targets. No workflow consumes these variables —ci.yml,publish.ymlandtag-command.ymlall shell out todotnet nbgv get-versioninstead — so nothing should break, but it does skip nbgv'sMSBuildPropertyUpdatesoutput.-m:1. Correct but slower.Workaround today: re-run the failed job.