|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
My organization (IXI Corporation/Equifax) are currently transitioning to a Jenkins CI system to help with deployments and box setup and configuration, to better support a swarm, and this plugin provides some very nice features to the system as a whole, I noticed this issue as well and started digging. I have created a potential fix to this error and I wanted some input.
What I have discovered and done:
Because of where the slave-setup injects itself into the slave start-up procedure, the OS of the slave doesn't seem to be available, no matter how I tried to retrieve it, the call you think might provide this value, is only available on the Master node, per the documentation.
I currently have a patch that I am using in our production system that uses a slave label of windows (case-insensitive) to determine whether to launch the shell or batch object.
Even with this change the plugin cannot be built on a windows box because of the echo command syntax in the unit test, but because of the way this unit test is preformed, I am able to query for the slave's OS and tweak the echo command accordingly to pass the test on windows (without effecting any-non windows builds) and allow for complete compilation and packaging.
What I wanted to discuss:
Would it be more desirable to automatically detect a Windows OS by try-catching the current plugin's process of starting the shell with the error it is expected to throw, automatically trying the batch alternative, and failing if neither are successful, as I don't want to force anyone to use labels they don't want.
I could even have the system skip the try-catch if the user decided to add a Windows label, effectively implementing both solutions, and reducing memory usage by skipping the overhead of a try-catch block.
Any input would be greatly appreciated.