1

I have a Powershell script which runs some Unity unit tests. On fail, this returns code 1, which Jenkins interprets as a fail and stops the current build. How do I avoid this behavior?

NOTE: This question is almost identical to this one, but that one uses bash, so I cannot apply it to my problem. In other words, how do I mimic the set +e behavior in Powershell? Alternatively, how do I tell Jenkins to ignore these script return codes and to continue the build anyway?

martorad
  • 165
  • 1
  • 12
  • I was able to circumvent this by adding an `exit 0` clause in my script, after running the unit testing, but this seems like going around the problem, instead of solving it. – martorad Sep 22 '21 at 13:47
  • 1
    One possibility is to use `try { } catch { }` block, or to use `powershell` with `returnStatus: true` (e.g. `def retVal = powershell(script: ', returnStatus: true)`. https://www.jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#powershell-powershell-script – Melkjot Sep 22 '21 at 13:50

1 Answers1

1

how do I mimic the set +e behavior in Powershell

You don't have to - it's the default behavior in that calls to external programs never[1] cause execution to stop prematurely, even if they report nonzero exit codes.

Alternatively, how do I tell Jenkins to ignore these script return codes and to continue the build anyway?

Ensuring that your script always terminates with exit 0 is indeed the correct way to ensure that Jenkins doesn't consider the script call failed (though you'll lose the information as to whether or not the tests failed).

[1] It can happen accidentally, due to flawed behavior up to PowerShell 7.1: If you use a 2> redirection and $ErrorActionPreference = 'Stop' happens to be effect, a script-terminating error occurs when stderr output is actually received. There is also pending RFC #277, which suggests introducing an opt-in mechanism for properly integrating external-program calls into PowerShell's error handling.

mklement0
  • 382,024
  • 64
  • 607
  • 775