PowerShell/pwsh steps do not fail on command not found, parameter not found or parameter validation errors

[rkeithhill]

Not sure if this is the correct repo for the GitHub/Azure DevOps powershell action that is used by PowerShell repo to build PowerShell. There's some inception level stuff going on here. :-) Anyway, this issue cropped on a PR build. We were having a hard time figuring out what was going wrong. It turns out that a PowerShell step was indicating it passed when it was clearly failing:

In fact, a few experiments with this repo's approach to executing PowerShell script shows that it fails in these other scenarios as well:

The fix is to execute the wrapper script using try { . 'path-to-ps1' } catch {throw} which causes these issues to return a non-zero exit code:

I recently made the same change to the Jenkins durable-task-plugin to fix the very same issue with the powershell/pwsh step in Jenkins pipelines. See my PR for that project.

I would suggest that the following tests for the PowerShell step be added to verify the current impl fails (red/green testing):

- pwsh: Get-CommandDoesNotExist

- pwsh: Get-Date -ParameterDoesNotExist

- pwsh Get-Date -Month 13 # invalid parameter value

- pwsh: Write-Host (1+)  # parse error - I think this works today but good to have a test if you don't already

[BALAGA-GAYATRI]

Hi @rkeithhill This repository's issues deals with issues on azure/powershell@v1 github action which is basically used by github workflows to run powershell scripts. Your issues included few of commandline errors as well which is not a part of this. If your workflow is using this action and getting errors, can you post your workflow and error details here.

[rkeithhill]

I think you misunderstand. What I'm pointing out is that GitHub workflows using this powershell action are fundamentally broken. The action can return Success when in fact the PowerShell action clearly FAILED (if you look at the output). The PowerShell commands I show above are just emulating how I see the AZ/GH PowerShell action invoking script.

What I provide above are examples of how the action gives false positives. If you added the tests that I suggest above you'd see that the PowerShell step indicates it passed when the script actually fails. This is bad news in a CI/CD system.

[BALAGA-GAYATRI]

hey @rkeithhill
This is from readme which can help.

Additionally the action supports two optional parameters

errorActionPreference :

• select a suitable  value for the variable for executing the script. Allowed values are stop, continue, silentlyContinue. Default is stop.

failOnStandardError :

• By default this is marked as false. But if this is marked as true, the action will fail if any errors are written to the error pipeline, or if any data is written to the Standard Error stream.

set this values appropriately to mark the action as failed incase of errors. Please try this and let us know if it helps.

[rkeithhill]

Hmm, stop is a sensible default for errorActionPreference. I see what is going on. The script being invoked is explicitly overriding the stop with $ErrorActionPreference = 'Continue'. That is why the Boostrap step indicates it succeeded when in fact it failed.