Build fails on one agent but not another due to warning from yarn
We have a few build agents which as part of the build runs a powershell script that executes `yarn install`. On our existing build servers this works fine, the command does produce some warnings, but the build continues and succeeds.
We have recently configured a new build server as we want to move then to another environment so cannot image the existing servers, but now running the same build configuration on the new server results in the build failing when a warning is output from `yarn install`.
Any ideas on what could be resulting in this change of behaviour between builds on different agents?
E.g. this message is output on one build server:
---
[3/4] Linking dependencies...
warning " > echarts-for-react@2.0.14" has unmet peer dependency "prop-types@^15.5.7".
...
[4/4] Building fresh packages...
---
And this on another:
---
[3/4] Linking dependencies...
Error: 4/22/2020 10:59:52 PM:
At C:\BuildFiles\xxx\src\build-web.ps1:161 char:10
+ exec { yarn install --frozen-lockfile }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: warning " > echarts-for-react@2.0.14" has unmet peer dependency "prop-types@^15.5.7".
Process exited with code 1
Process exited with code 1 (Step: Run build script (PowerShell))
Step Run build script (PowerShell) failed
---
Please sign in to leave a comment.
Hello,
TeamCity simply evokes the PowerShell script with no extra logic on top of that. From what I could see, it`s either yarn that began to report this warning as error (however, quick documentation reference did not hint of a way to do that with yarn config), or PowerShell itself is treating the warnings from subprocess (yarn install) as a flag to raise exception and stop subprocess. On that note, do you use this or similar exec definition? {https://gist.github.com/jpoehls/2843721}
Let me suggest to run the PowerShell script in question from the checkout folder on this agent instance, using the same identity as the one agent has (please mind the details about how agent service runs by default on Windows: https://www.jetbrains.com/help/teamcity/setting-up-and-running-additional-build-agents.html#SettingupandRunningAdditionalBuildAgents-BuildAgentasaWindowsService). I believe that you should see the same output on manual execution, but possibly with extra information from PowerShell itself regarding why command execution has failed.
Hi Fedor, thanks for those suggestion and this was the path I was going down. I have since changed the TC agent to run as a specific user account rather than Local System and have tested running the build as that user from a powershell console. It does work fine from the console and no Exceptions are raised. However I still get the same behaviour when running the build script from the TC agent.
I did try setting some powershell options like $ErrorActionPreference="SilentlyContinue" which does allow the build to progress past the warnings that are being generated from yarn, but it also results in no output to the build log with the warnings. I'm then also finding any external process that is called from the build script that generates a warning results in an Exception from powershell and fails the build.
You are correct, the exec function is from psake, the same as the one you've linked.
The main problem I'm coming up with is that I can run the exact build command in a console and it runs through without error (with warnings generated in the console output), but when run from the TC Agent, the warnings become errors and fail the build.
I'd appreciate any further suggestions, thanks!
Hello Jeremy,

So far, every option we could think of which would influence agent running PS step to raise subprocess warning to exception would affect all agents. The behaviour you are facing looks weird - may I ask you to provide hidden artifacts from a build which took place on agent in question? You can do so in a private manner via "Submit a request" form.
Are there any other noteworthy differences in the setup on this agent (i.e. PowerShell version, Windows edition, update policy)?
As a quick test, if you would exec a custom script which includes two statements: first Write-Warning (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/write-warning?view=powershell-7), then Write-Error (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/write-error?view=powershell-7) to simulate different output levels, which one will agent fail on?
I've uploaded the .teamcity folder from one of the builds, https://teamcity-support.jetbrains.com/hc/en-us/requests/2627922
This is a successful build where I set $ErrorActionPreference="SilentlyContinue" in each step that calls an external process.
For your test of Write-Warning and Write-Error all build agents output the same result:
[12:58:53]W: Step 1/1: Test (PowerShell) (1s)
[12:58:53]i: [Step 1/1] PowerShell running in non-virtual agent context
[12:58:53] : [Step 1/1] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[12:58:53] : [Step 1/1] Working directory: C:\BuildAgent\work\33c5785711afa534
[12:58:53] : [Step 1/1] Command: C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe
[12:58:53] : [Step 1/1] PowerShell arguments: -Version, 4.0, -NoProfile, -NonInteractive, -ExecutionPolicy, ByPass, -File, C:\BuildAgent\temp\buildTmp\powershell5368198752016116672.ps1
[12:58:54] : [Step 1/1] WARNING: This is only a test warning.
[12:58:55]W: [Step 1/1] C:\BuildAgent\temp\buildTmp\powershell5368198752016116672.ps1 : This is only a
[12:58:55]W: [Step 1/1] test error.
[12:58:55]W: [Step 1/1] + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorExcep
[12:58:55]W: [Step 1/1] tion
[12:58:55]W: [Step 1/1] + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio
[12:58:55]W: [Step 1/1] n,powershell5368198752016116672.ps1
[12:58:55]W: [Step 1/1]
[12:58:55] : [Step 1/1] Process exited with code 0
One note difference is the newer build agent is running Windows Server 2019, vs our other agents are either Windows Server 2012R2 or 2016. I'm going to try setting up another agent using Server 2016 to see if I get the same issues using the new setup process.
Another follow-up, I have since configured a Windows Server 2016 machine using the same setup process and the agent running on this machine does not have the issue that the 2019 server does. I get the same warning messages in the log output but the build does not fail like it does on Server 2019. So definitely seems to be a Server 2019 issue. It would still be good to get to the bottom of what is causing this as we would like to be using Server 2019 as I'm sure other people will be too and may hit this same problem.