Arcade: darc is not a recognized cmdlet

Created on 28 Jul 2020 · 23Comments · Source: dotnet/arcade

[x] This issue is blocking
[x] This issue is causing unreasonable pain

For Validation-for-Promotion pipeline runs that have Arcade validate on branches of bellwether repos, the execution of the build-arcadewithrepo.ps1 script is failing at https://github.com/dotnet/arcade-validation/blob/master/eng/validation/build-arcadewithrepo.ps1#L233 for the Installer repo.

The logs show that darc was installed on the machine.

Example build failure: https://dnceng.visualstudio.com/internal/_build/results?buildId=748175&view=logs&j=6989144e-9c50-5586-7b61-a9af8cea5132&t=c78d63a3-c8c6-513a-1baf-fae22b0d7c09

Error:

D:\a\1\s\eng\validation\build-arcadewithrepo.ps1 : The term 'darc' is not recognized as the name of a cmdlet, 
function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the 
path is correct and try again.
At D:\a\_temp\dadf87a8-539d-4403-b166-9880f75e820d.ps1:3 char:1
+ eng\validation\build-arcadewithrepo.ps1 -azdoOrg dnceng -azdoProject  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (darc:String) [build-arcadewithrepo.ps1], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException,build-arcadewithrepo.ps1

First Responder

Source

missymessa

All 23 comments

This is now occurring for regular Arcade Validation pipeline on the Validate Publishing stage: https://dev.azure.com/dnceng/internal/_build/results?buildId=748212&view=logs&j=56ebfe15-69d8-5dd1-65e4-c65998c8d8a6&t=0a9483a6-3ac1-5fd2-c450-3586b050b65b

missymessa on 28 Jul 2020

Has this actually worked before? This is failing because of this line in the logs:

Since you just installed the .NET SDK, you will need to reopen the Command Prompt window before running the tool you installed.

The darc we just installed isn't in a place that is on the current process path, a refreshenv might work, but if this was working and now isn't thats strange.

alexperovich on 28 Jul 2020

Yep, checked one of the builds that worked, it doesn't have that line.

alexperovich on 28 Jul 2020

Yeah, this worked before (and in one run of the validation for promotion pipeline, the two other bellwether repo builds worked find, just not Installer). Aside from Arcade updates into Arcade Validation, I've been the only one making changes to this repo, and the last time I made a change was last week :/

missymessa on 28 Jul 2020

I see what changed, the successful build was run on a Hosted Pool, the failed build was changed to run on the helix queues. Our helix queues don't have dotnet cli installed globally, so this code doesn't handle that case. This build should probably be changed back to a hosted pool unless there is a strong reason to use the helix pools.

alexperovich on 28 Jul 2020

successful build: https://dev.azure.com/dnceng/internal/_build/results?buildId=747339&view=logs&j=56ebfe15-69d8-5dd1-65e4-c65998c8d8a6
failed build: https://dev.azure.com/dnceng/internal/_build/results?buildId=748212&view=logs&j=56ebfe15-69d8-5dd1-65e4-c65998c8d8a6

alexperovich on 28 Jul 2020

Unless I'm going crazy, https://dev.azure.com/dnceng/internal/_build/results?buildId=748212&view=logs&j=56ebfe15-69d8-5dd1-65e4-c65998c8d8a6 which failed ran in a hosted pool

riarenas on 28 Jul 2020

Our helix queues don't have dotnet cli installed globally

Has this ever been true?

markwilkie on 28 Jul 2020

What is going on? I was literally just looking at that build, and it said it used a helix pool. I reload the page and it changed.

alexperovich on 28 Jul 2020

👀1 😕1

Some of the helix queues do have it installed globally, but that isn't true of all of them.

alexperovich on 28 Jul 2020

More and more this looks like a problem/change with the configuration of the hosted pool machines. The build failure can be fixed by sticking a refreshenv between the tool install and darc <stuff>. That will fix the problem, and should probably be done anyways so that the build doesn't depend on machine state.

The build could also install darc as a "local tool" and run it with dotnet tool run darc that would be even more isolated from machine state.

alexperovich on 28 Jul 2020

Should we just stick a function to refresh the environment as a final step in the darc install script?

riarenas on 28 Jul 2020

👍1

Putting refreshenv in the darc install script wouldn't fix it I think. It only refreshes the environment for the current session, not parent ones, so if you were calling the install script from another script, that other script wouldn't get the proper environment.

alexperovich on 28 Jul 2020

I can add a refreshenv YAML task in our release/validation pipelines that run darc-init.ps1 and see if that fixes installer runs