Problem
Job step exit code is very important as it is used to decide the result of the job step (which in many cases decides the procedure result and often used as a condition by following steps). In some cases, the job step exit code (thus the job step result) is not natural.
For example, a job run from the procedure in the following screenshot (please check the commands of the steps in the screenshot)
will get the result in this picture:
Explanation
The result may be different to the result you expect. In order to understand why we get this result, we should first understand how these command are run by the flow agent.
By default (in Windows) the flow agent uses "cmd.exe" as the shell to run the step commands. This can also be confirmed from the agent log:
2019-11-08T16:56:58.291 | INFO | 0xcb4120 | Parsed request: cmdId: run-b7a1883c-0205-11ea-b60c-6cb920524153-b7c2cb3b-0205-11ea-b513-6cb920524153 cwd: shell: command: c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\amd64\MSBuild.exe /version
REM THIS IS A COMMENT LINE stdout: //flowserver/commander-workspace/job_1931_20191108165656/test_and_result_in_s.b7c2cb3b-0205-11ea-b513-6cb920524153.log postpShell: postpCommand: userName:
2019-11-08T16:56:58.291 | DEBUG | 0xcb4120 | Updated shell: cmd /q /c "{0}.cmd"
2019-11-08T16:56:58.291 | DEBUG | 0xcb4120 | Converting command-block to CRLF line terminations.
2019-11-08T16:56:58.291 | DEBUG | 0xcb4120 | Final cmd to send to run: C:/Program Files/Electric Cloud/ElectricCommander/bin/ecwrapper 0 "" 4 cmd /q /c "C:\Windows\TEMP\ecmdrAgent/agent.HHFESABH7FJTGIU8.run-b7a1883c-0205-11ea-b60c-6cb920524153-b7c2cb3b-0205-11ea-b513-6cb920524153.cmd" "//flowserver/commander-workspace/job_1931_20191108165656/test_and_result_in_s.b7c2cb3b-0205-11ea-b513-6cb920524153.log" ""
2019-11-08T16:56:58.291 | DEBUG | 0xcb4120 | About to run command file: C:\Windows\TEMP\ecmdrAgent/agent.HHFESABH7FJTGIU8.run-b7a1883c-0205-11ea-b60c-6cb920524153-b7c2cb3b-0205-11ea-b513-6cb920524153.cmd
Please note that the commands are stored to an "cmd" file and then run by "cmd /q /c".
So we can run the commands in the same way and check the results. Here’s the result when running them in command window (which is actually cmd.exe):
c:\test>type test_and_result_in_failure.cmd c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\a md64\MSBuild.exe /version c:\test>cmd.exe /q /c test_and_result_in_failure.cmd 'c:\Program' is not recognized as an internal or external command, operable program or batch file. c:\test>echo %errorlevel% 1 c:\test>
c:\test>type test_and_result_in_success_1.cmd c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\a md64\MSBuild.exe /version echo abc c:\test>cmd.exe /q /c test_and_result_in_success_1.cmd 'c:\Program' is not recognized as an internal or external command, operable program or batch file. abc c:\test>echo %errorlevel% 0 c:\test>
c:\test>type test_and_result_in_success_2.cmd c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\a md64\MSBuild.exe /version REM THIS IS A COMMENT LINE c:\test>cmd.exe /q /c test_and_result_in_success_2.cmd 'c:\Program' is not recognized as an internal or external command, operable program or batch file. c:\test>echo %errorlevel% 0 c:\test>
With this test, we can conclude that flow agent strictly follow the result from the shell (in this case, cmd.exe).