I am running into a problem of a task exiting with a null exit code. And with this exit code, I noted that I can't access files on node to check the stderr and stdout files. What could be the problem? Also, what does a null exit code mean and how can I set the exit code to be not nullin case of failure?
Thanks!
You will want to check the task's failureInfo field within the executionInfo property.
There is a difference between task failure and application logic failure for the process (command to execute) that is executed under the task. A task failure can be a multitude of things such as a resource file for a task failing to download. A process failing to launch properly for some reason is also a task failure. However, if the process does launch and execute, but the process itself "fails" (as per application logic) and returns a non-zero exit code and no other issues are encountered with the task, this task will have the proper exit code saved. Thus, if a task completes with a null exit code, you will need to consult the failureInfo field as per above along with any stdout/stderr logs if they exist.
Related
I have a PowerShell task in my definition that calls another script file on its own which takes care of running several things on my build agent (starts several different processes) - emulators, node.js applications, etc.
Everything is fine up until the moment this step is done and the run continues. All of the above mentioned stuff gets closed with most of the underlying processes killed, thus, any further execution (e.g. tests run) is doomed to fail.
My assumption is that these processes are somehow dependent on the outermost (temporary) script that VSTS generates to process the step.
I tried with the -NoExit switch specified in the arguments list of my script, but to no avail. I've also read somewhere a suggestion to set this by default with a registry key for powershell.exe - still nothing.
The very same workflow was okay in Jenkins. How can I fix this?
These are the tasks I have:
The last PowerShell task calls a specified PowerShell file which calls several others on its own. They ensure some local dependencies and processes needed to start executing the tests, e.g. a running Node.js application (started in a separate console for example and running fine).
When the task is done and it is successful, the last one with the tests would fail because the Node.js application has been shut down as well as anything else that was started within the previous step. It just stops everything. That's why I'm currently running the tests within the same task itself until I find out how to overcome this behavior.
I am not sure how you call the dependencies and applications in your PowerShell script. But I tried with the following command in PowerShell script task to run a Node.js application:
invoke-expression 'cmd /c start powershell -Command {node main.js}'
The application keeps running after the PowerShell script task is passed and finished which should meet your requirement. Refer to this question for details: PowerShell launch script in new instance.
But you need to remember to close the process after the test is finished.
There is the Continue on error option (Control Options section). The build process will be continued if it is true (checked), but the build result will be partially succeeded.
You also can output the error or warning by using PowerShell or VSTS task commands (uncheck Fail on Standard Error option in the Advanced section) and terminate the current PowerShell process by using the exit keyword, for example:
Write-Warning “warning”
Write-Error “error”
Write-Host " ##vso[task.logissue type=warning;]this is the warning"
Write-Host " ##vso[task.logissue type=error;sourcepath=consoleapp/main.cs;linenumber=1;columnnumber=1;code=100;]this is an error "
More information about the VSTS task command, you can refer to: Logging Commands
So I defined a Rundeck job which normally executes three steps:
run script to check remote directory for .csv files and rsync them
manipulate csv files
rsync the csvs back to remote dir
now I set up the script run on step 1 to finish with exit code 1 when there are no csv files in my remote directory, upon which it does not execute steps 2 and 3 - which is great! But the whole job is marked as having failed even though it just didn't need to execute the other steps.
Is it possible to conditionally execute steps 2 and 3 of my job such that if step 1 fails it is still marked as 'succeeded'?
It is possible with Rundeck Error Handlers.
You will need to use the job context variable ${result.resultCode} in your error handler code in order to get a return code.
As you don't want the job marked as failed after the Error Handler was successfully executed, you need to tick Keep going on success from WebUI or add keepgoingOnSuccess="true" to you job definition code.
But after the error handler was successfully executed, the job will continue step 2 and step 3, where you may need to inject your step 2 code for it.
When putting together a release definition in VSO, adding an Azure PowerShell
task
backed by a file Script1.ps only containing exit 1 does not fail the step when it runs - which I would expect it to do, given that the Continue on error box is not checked
If I add the PowerShell task, writing exit 1 using the inline variant would indeed fail the step. This also comes with an 'advanced configuration option' where the Fail on Standard Error is checked by default.
What did I miss? How would I go about making the Azure Powershell fail in the same manner?
Using this code instead:
[Environment]::Exit(1)
The task will fail if the script throws an exception or writes to stderr stream.
I'm writing a simple function to test whether Cassandra is running on the local machine (by capturing the output of service cassandra status. The problem is that this command always exits with a bad return status of 3. I have successfully called service cassandra stop immediately prior to this command, and have even tried running status in a loop to see if there was some race condition (it seems to reliably fail with status 3 for a long time). However, running service cassandra status through the shell works. Any ideas what the issue may be, or even just how to debug this?
private def isCassandraStopped(): Boolean = {
val s = Seq("sudo", "sh", "-c", "service cassandra status").!!
val r = " * Cassandra is not running" == s
if (!r) logger.info(s"Cassandra is not stopped: #$s#")
r
}
This is the line that succeeds prior to executing the above method:
Seq("sudo", "sh", "-c", "service cassandra stop").!
If you are reading process output with !! any non-zero exit status throws an exception by default as described in the docs. You can try to work around it and read the output as well as get the process exit status in ways described here.
By default exit status 3 should mean that the program is not running as described here. However, this might not be respected by your init script. So the best thing is to read the script and make sure that it returns the exit code 3 in that case.
So your options are:
read the exit code only if it's reliable
check how your run script is implemented and duplicate the process status check logic yourself - usually it checks that pid file exists and the process with that pid is running (checkpid).
read both output and exit status as described in other SO QAs
read all lines without throwing an exception with lines_!: Process("your command here").lines_!. You will not have an exit status in this case.
Usually exit status is more reliable in properly written shell scripts than output parsing.
I have a Powershell script written, which will be used in an automated build process.
Do I need to write exit code 0 when the script will take the correct path (e.g. doesn't go into the if blocks which indicate an error condition)?
Also, what is the difference between exit (with code) and $host.SetShouldExit()?
In similar scenario I rely on exceptions (throw) and other kind of terminating errors: the PowerShell’s exit code is 1 in that case. If a scripts finishes itself (even with not terminating errors) then PowerShell’s exit code is 0, we do not have to call exit 0. If we need something but 0 and 1 then indeed we have to use exit or SetShouldExit (but see remarks below).
Let’s take a look at the scripts.
test1.ps1
'before2'
.\test2
'after2'
'before3'
.\test3
'after3'
'before4'
.\test4
'after4'
test2.ps1
'inner before 2'
exit 2
'inner after 2'
test3.ps1
'inner before 3'
$host.SetShouldExit(3)
'inner after 3'
test4.ps1
throw 'Oops'
Output of the test1.ps1:
before2
inner before 2
after2
before3
inner before 3
inner after 3
after3
before4
Oops
At ...
+ throw <<<< 'Oops'
In this test scenario the test4.ps1 kind of works and test2.ps1 and test3.ps1 kind of do not work (if to work means to fail and exit the session immediately).
The output shows that exit terminates the current script and SetShouldExit does not.
The exit code of powershell.exe .\test1 is 3 due to $host.SetShouldExit(3). I have tried to disable that line to check whether exit 2 makes the exit code to be 2. No, it does not, the exit code is 1 due to the failure in test4.
I have noticed one more difference. If I call a script from the interactive PowerShell console than $host.SetShouldExit in a script makes the console to close after the call. exit does not.
A thought. Behaviour of $host.SetShouldExit may depend on implementation of a host. For example, in one my own host exit is not supported at all (it is not allowed to close the hosting application just like that) and my implementation of SetShouldExit basically does nothing at all.