|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Perspective. Technically I agree that no build is impacted by marking a node offline - I can address the issue and resume the build. However, my issue is that I have a department full of developers and ScrumMasters that are relying on our full nightly build being completed and waiting when they come in the next day. I can't afford to fall below my threshold and queue up the remainder of that process due to offline node. So my non-technical perspective (and that of my management I expect) is that I effectively failed the build/deploy/test process by causing a significant delay. Big impact on human resources.
I agree that a soft/warning threshold would meet the requirement for a proactive solution that doesn't suspend a running build.