|
||||||||
|
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 [email protected].
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.