Open bitwit opened 9 years ago
Could be a setting on the runner, like a default timeout value, which is set to 'never' by default.
yes, we used to have this hard coded to 45 minutes. it sounds like it was lost in a refactor. but we definitely should have it.
On Monday, December 1, 2014, Ilya Radchenko notifications@github.com wrote:
Could be a setting on the runner, like a default timeout value, which is set to 'never' by default.
— Reply to this email directly or view it on GitHub https://github.com/Strider-CD/strider/issues/656#issuecomment-65116673.
Niall O'Higgins W: http://niallohiggins.com E: n@niallo.me T: @niallohiggins
We had an issue today where a deploy task failed to execute properly and left the job hanging indefinitely. Then our Strider got backed up with jobs from everyone's commits over the morning.
Wondering if Strider should have a project settings for maximum job length before timeout as a failure. If any of our jobs take over 10m we are very confident it's a fail, for example.
Any thoughts on this? I assume containerizing/using docker runner overcomes this problem, but simple runner gets held up.