Azure-pipelines-tasks: AzureCLIV2 doesn't display output of Write-Error

[qetza]

When using the AzureCLI task with powershell core (and maybe powershell) the output of Write-Error cmdlet is not displayed as it is done with other powershell tasks.

- task: AzureCLI@2
  displayName: Write-Error
  inputs:
    azureSubscription: '$(ServiceConnection.AzureSubscription)'
    scriptType: pscore
    scriptLocation: inlineScript
    failOnStandardError: true
    inlineScript: Write-Error "oops"

The previous task execution should display the error message in red ##[error]oops but instead only the following error is displayed:

##[error]Script failed with error: Error: The process 'C:\Program Files\PowerShell\7\pwsh.exe' failed with exit code 1

This is a big issue as any error output in the executed script is masked.

The current workaround i found is to use a try/catch and manually logs the error:

- task: AzureCLI@2
  displayName: Write-Error
  inputs:
    azureSubscription: '$(ServiceConnection.AzureSubscription)'
    scriptType: pscore
    scriptLocation: inlineScript
    failOnStandardError: true
    inlineScript: |
      try
      { 
        Write-Error "oops"
      }
      catch
      {
        Write-Host "##vso[task.logissue type=error]${_}"
        exit 1
      }

The AzureCLI task should support powershell cmdlets Write-Debug, Write-Verbose, Write-Warning and Write-Error by displaying them in the logs with the correct log level.

[hbuckle]

As far as I can tell it's to do with the upgrade to powershell 7, which has a new ErrorView
If you set $ErrorView = "NormalView" at the top of the script it should display errors. I'm not sure if it's an issue with PowerShell, the agent or the task library
https://github.com/microsoft/azure-pipelines-agent/issues/2853

[qetza]

Thanks, adding $ErrorView = "NormalView" indeed makes the error written to the logs but not as an error (in red prefixed with ##[error].

Using the PowerShell task (on pwsh 7.0), even without $ErrorView = "NormalView" the error is display in the logs as an error:

##[error]Write-Error: oops
##[error]PowerShell exited with code '1'.

So it seems that the AzureCLI task could also support this.

[vineetmimrot]

Thanks @qetza for filing the issue. We will revert back soon with the solution.

[MattJeanes]

I'm not sure why this has been labelled as a question, this seems to definitely a bug in the Azure CLI V2 task, as others mentioned the normal Powershell task shows errors correctly and completely hiding the error is a breaking change between Powershell Core 6 and Powershell 7 which upgraded silently in the agent image.

[qetza]

Now the pwsh task is also not displaying errors if $ErrorView = 'ConciseView' which is the new default value for powershell 7.0.
I think this should be handled by the tasks to make sure that the new default error view of powershell are supported.

[apobekiaris]

i am not using the cli but the Azure Devops powershell task and they upgraded to v7 and guess whatt it is impossible to debug my pipes anymore. To provide a meaning full error display i have to switch all my yml to inline script because it is only the possible to make the call $ErrorView="NormalView" before the script is executed.

error output with NormalView

##[command]"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'd:\a\_temp\1570bf91-742d-48a4-bb4d-60b0d754ad30.ps1'"
No OAuthSettings was found. Use 'Set-TwitterOAuthSettings' to set PSTwitterAPI ApiKey & Token.
At C:\Users\VssAdministrator\Documents\PowerShell\Modules\PSTwitterAPI\0.0.7\public\Get-TwitterOAuthSettings.ps1:35 char:9
+         Throw "No OAuthSettings was found. Use 'Set-TwitterOAuthSetti …
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OperationStopped: (No OAuthSettings wa…API ApiKey & Token.:String) [], RuntimeException
+ FullyQualifiedErrorId : No OAuthSettings was found. Use 'Set-TwitterOAuthSettings' to set PSTwitterAPI ApiKey & Token.
##[error]PowerShell exited with code '1'.
##[section]Finishing: Release

Error output with ConsideView

```Formatted command: . 'd:a1sScriptsNotify-New-DevExpress.Version.ps1' * **
========================== Starting Command Output ===========================

[command]"C:Program FilesPowerShell7pwsh.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'd:a_tempbca11391-05a9-48ea-b281-fb6068b0f8f7.ps1'"

[error]PowerShell exited with code '1'.

[section]Finishing: Release

```

[error]PowerShell exited with code '1'.

it beats me why such a meaningless line takes priority

[bishal-pdMSFT]

Thanks for pointing out the issues. We are looking into this.

[apobekiaris]

and a small not however of huge importance, powerrshell 7 upgrade hurt my bussiness to the maximum without the option to choose another working version like v6.

From my experience 20+ years coder it is almost certain to hit walls when u ugrade and your policy switching versions makes me reconsider if DevOps is my tool in the future.

I already posted a ticket in AzureDevops support however they blame powershell 7 and said they will do nothing Hmm I do not care who is to blame I only know that my resources were spent in vain since v7 switch and my customers are disappointed

[bishal-pdMSFT]

I can understand your pain @apobekiaris. One not so good workaround is to use private agents.

@chshrikh @alepauly do you know who should we contact for PowerShell ecosystem on Hosted agents?

[apobekiaris]

Although DevOps provides free agents to OS projects, we put working hours and we advertise DevOps so they not like free for nothing. As I see it in this free agent deal our part is done, so DevOps must at least respect our work and not experiment with it, we are not playing games and we have a family to feed.

One not so good workaround is to use private agents.

Thanks for trying to help and understand however this is not an option the cost of 10 agents is enormous for my business.

[issacnitin]

@apobekiaris The issue is fixed and deployed for Azure CLI, I tried running a script with "Write-Error", and I got this as part of logs:

##[error]D:\a\1\s\init.ps1 : oops

Could you please revert if the issue is fixed for you as well?

[issacnitin]

@apobekiaris I'm closing the issue for now, as I couldn't get a response from you. Please feel free to re-open in case of any queries or if the issue persists.