|
||||||||
|
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.

I guess it depends on usecase.
If the instance is stopped at -5 minutes and another job comes in at -4, there will be a short delay on that next job while the instance is restarted, but it won't really cost any more than it would have done if the instance had been left running.
But if I have a job finish at -2 and then keep the instance running 5 minutes in case another job comes, then I have to pay a whole extra hour for no reason.
Generally for us, if a build fails and there's nothing in the queue it's at least a few minutes, often longer, before we've found the failure and pushed the fix. So the behaviour as-is works fairly well for us.
Perhaps actually what's needed is a configurable idle time (after last job completion) and a "Wait till the end of an instance-hour to stop instances" checkbox. Stopping an instance takes a fairly consistent amount of time, and I don't think there's a usecase where you'd intentionally want to stop it with say half an hour left? So the minutes left cutoff could just be hardcoded - say 2 minutes before the hour, to be safe.
Then the logic would be something like: