-
Bug
-
Resolution: Won't Fix
-
Major
-
None
-
Windows 10 Pro slave using jnlp start
We have Jenkins master running on Ubuntu 14.04 with Windows 10 Pro and Mac OSX slaves. All seem to be working normally except for the Windows 10 slave. If ANY testcases fail (even just one) then the build/run is marked a failure. We have a pass percentage of 95% and an unstable percentage of 90% set for the build and this is working for everything EXCEPT Windows 10. The Windows 10 machine is using the WebStart jnlp file to connect to the master machine, the same as the Mac OSX box is using.
[JENKINS-41560] Robot Framework plugin on Windows not honoring passed/unstable percentages
Jerry Schneider
added a comment - At the time I submitted this issue, no I was not using the --nostatusrc flag. Right now I am using it ONLY on my Windows Slaves, the Linux and Mac boxes are NOT using this flag. I am a little puzzled as to why it is required on Windows but not Mac or Linux?
Jerry Schneider
added a comment - At the time I submitted this issue, no I was not using the --nostatusrc flag. Right now I am using it ONLY on my Windows Slaves, the Linux and Mac boxes are NOT using this flag. I am a little puzzled as to why it is required on Windows but not Mac or Linux?
jpiironen
added a comment - Hiya, Robot Framework returns the number of failed critical test cases as the return code after each run. Non-zero return codes will fail the 'execute shell' or 'batch' build step on any OS, which renders using the pass percentage as a threshold for failed/unstable build meaningless in many use cases. If the build result is already marked failed when the plugin kicks in, it won't change it. Forcing the exit code to be always zero with --nostatusrc will always pass the shell/batch build step and leave the decision of pass/fail/unstable to the plugin (or other steps run afterwards).
Is your robot run the same on the other OS or are you perhaps using some other shell commands or flags to make the non-zero return code not count?
jpiironen
added a comment - Hiya, Robot Framework returns the number of failed critical test cases as the return code after each run. Non-zero return codes will fail the 'execute shell' or 'batch' build step on any OS, which renders using the pass percentage as a threshold for failed/unstable build meaningless in many use cases. If the build result is already marked failed when the plugin kicks in, it won't change it. Forcing the exit code to be always zero with --nostatusrc will always pass the shell/batch build step and leave the decision of pass/fail/unstable to the plugin (or other steps run afterwards).
Is your robot run the same on the other OS or are you perhaps using some other shell commands or flags to make the non-zero return code not count? Jerry Schneider
added a comment - For now, I have added "–nostatusrc" to all my windows jobs, but it is not on the Linux or Max OS X jobs. The Linux and Mac OS X jobs are running normally and honoring the percentages entered for the Robotframework plugin. Windows is now honoring it as long as I have the "–nostatusrc" flag. Why the difference between the operating systems?
Jerry Schneider
added a comment - For now, I have added "–nostatusrc" to all my windows jobs, but it is not on the Linux or Max OS X jobs. The Linux and Mac OS X jobs are running normally and honoring the percentages entered for the Robotframework plugin. Windows is now honoring it as long as I have the "–nostatusrc" flag. Why the difference between the operating systems?
Hi jerry57,
Sorry for the long delay in response. Is this still an issue? Do also note that the plugin is not for running Robot Framework tests, just for publishing the results you have already got.
I'm not sure why the different OS behave (or have behaved) differently. I've used --nostatusrc on all my jobs regardless of OS. As far as I know, this shouldn't work even on Linux/OS X without the flag.
Closing because not enough info. Doesn't seem to be an issue anymore.
Just to verify, you are running robot with --nostatusrc option?