MSBuild fails: Environment variable too long

Continua CI Bugs
1

Hi Support Team,

we use a ContinuaCI Build Server to build C# programs via FinalBuilder-Actions ('Build VS.Net Solution' and 'MSBuild Project'). After update to v1.8.1.938 they fail with the following error:

MSBuild Properties

Configuration="Release"
Platform="Any CPU"
OutDir=C:\ContinuaCI\Agent\Ws\18484\GuckstDu\Bin\
Running C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe with parameters : /t:Rebuild /nr:false /logger:FinalBuilderLogger,"C:\Program Files (x86)\FinalBuilder 7\FinalBuilder.MSBuild.Logging.v4.0.dll" /noconlog /p:Configuration="Release";Platform="Any CPU";OutDir=C:\ContinuaCI\Agent\Ws\18484\GuckstDu\Bin\ /v:normal /m "C:\ContinuaCI\Agent\Ws\18484\GuckstDu\DotNet\GuckstDu_DotNet.sln"
------
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 28.06.2018 16:19:33.

Unhandled Exception: Microsoft.Build.Shared.InternalErrorException: MSB0001: Internal MSBuild Error: Environment variable name or value is too long.
=============
System.ArgumentException: Environment variable name or value is too long.
at System.Environment.SetEnvironmentVariable(String variable, String value)
at Microsoft.Build.BackEnd.InProcNode.HandleShutdown(Exception& exception)
at Microsoft.Build.BackEnd.InProcNode.Run(Exception& shutdownException)

---> System.ArgumentException: Environment variable name or value is too long.
at System.Environment.SetEnvironmentVariable(String variable, String value)
at Microsoft.Build.BackEnd.InProcNode.HandleShutdown(Exception& exception)
at Microsoft.Build.BackEnd.InProcNode.Run(Exception& shutdownException)
--- End of inner exception stack trace ---
at Microsoft.Build.Shared.ErrorUtilities.ThrowInternalError(String message, Exception innerException, Object[] args)
at Microsoft.Build.BackEnd.InProcNode.Run(Exception& shutdownException)
at Microsoft.Build.BackEnd.NodeProviderInProc.InProcNodeThreadProc()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
[Error] msbuild.exe returned Error code : 255

I've added an execute action just before the MSBuild action (cmd /c set), which revealed a suspicious environment variable:

ContinuaCI.Build.ChangesetRevisions=131516dd5756798818d4bf72c2910.... and several more letters - to be exact: the length after the eqal sign is 8155.

This drawed my attention to a fact equal to all failed builds: the amount of changesets for these builds are very high (more than 1000).

I have no idea, why ContinuaCI determines more than 1000 changesets because in fact there are only a few since the last build. But I'm sure that the reason why MSBuild will fail is the very large environment variable (ContinuaCI.Build.ChangesetRevisions).

Would you mind to consider this variable not to exceed a specific length (I assume it is not required by MSBuild.exe)? The threshold should suit to MSBuild restrictions.

If not: is it possible for me to remove this environment variable before I start the MSBuild related actions?

Any help is very appreciated because we are currently incapable of providing new software builds.

Best regards

Michael

2

Hi Micheal,

We'll add a limit to the size of the environment variables and make this configurable as as limit appears to be dependant on version of MSBuild and the operating system. We'll get this update out by the beginning of next week.

The number of changesets associated with a build depends on the Default Associated Changesets setting in the Details tab of the configuration wizard. This can be overridden using the Associate drop-down on the Queue Options dialog. It appears that you have this set to "All changesets since last successful build". If you set this to "Most recent changesets" you should then be able to get the builds running again. Alternatively, if you are not making use of the environment variables, you can switch off the option "Generate system environment variables" in the MSBuild action and any preceding actions where this option is available.

We'll like to figure out why there are so many changesets. You mentioned that there are only a few since the last build - how about since the last successful build? What type of repository are you using? It is possible that you recently merged a large number of changesets into the current branch? Are you building from a branch or a tag?

3

Hi Dave,

thank you for you answer.

We prefer to use ‘all changesets…’ because this provides a list with the commits contained in the build. ‘Most recent changeset’ shows only the latest commit.

We use GIT and mainly build the develop branch. We recently had a release. After releases we merge the develop branch into the master branch. After the most recent merge there already have been successful builds of the develop branch for the next BuildVersion.

We use support branches (e.g. master > support/v3.2.1) to build patches for older versions.

In ContinuaCI the user selects the branch to be build. Usually the build is started for the branch ‘develop’ and from time to time for a ‘support/vx.y.z’ branch.

It seems that the most recent build of develop was before we’ve had some builds for a support branch. The next build for develop found obviously too much commits.

Is this information what you requested? Hope this helps…

In the meantime I started a build using ‘most recent changeset’ instead of ‘all changesets…’ - and the build was successful. I started again with ‘all changesets…’ and it shows 1 commit (not >1000). Many thanks for your support.

Best regards
Michael

4

Hi Micheal,

Thanks for the additional information and great that you managed to work around this.

We have added a property to allow you to set the maximum environment variable length for the next version which we'll release once we've fixed some other issues.

We'll also investigate whether it's feasible add an option to change the build changeset association to only include first-parent commits for Git repositories.

5
Posted By Administrator Account on 29 Jun 2018 12:14 AM

We'll also investigate whether it's feasible add an option to change the build changeset association to only include first-parent commits for Git repositories.

Hi,

recently i've discussed an option with Dave to filter for "first-parent-only" in the [Changes] tab. From reading this suggestion i guess it is inspired by this. Sounds reasonable to not include changesets not neseccasary for the build anyway. I like it and would probably use it right away. It might make handling Git-changesets easier also.

Thomas