-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build should time out if it takes more than X hours #195
Comments
jlebon
changed the title
Build should time out if build takes more than X hours
Build should time out if it takes more than X hours
Feb 6, 2020
👍 |
hit this again.. I just killed https://jenkins-fedora-coreos.apps.ci.centos.org/job/fedora-coreos/job/fedora-coreos-fedora-coreos-pipeline/11960/ which has been running almost a day. |
jlebon
added a commit
to jlebon/fedora-coreos-pipeline
that referenced
this issue
Mar 25, 2020
Let's cap build runs to 3h. Builds should never take that long. Ideally, we'd do timeouts per stage, and that could make sense (e.g. signing for example could in the worst case take more than 1h, but building the qcow2 shouldn't really take more than 15m), though just having one overall timeout to start with will at least prevent jobs from getting stuck anywhere in the process forever and taking up a pod in a cluster. Closes: coreos#195
jlebon
added a commit
to jlebon/fedora-coreos-pipeline
that referenced
this issue
Mar 26, 2020
Let's cap build runs to 4h. Builds should never take that long. Ideally, we'd do timeouts per stage, and that could make sense (e.g. signing for example could in the worst case take more than 1h, but building the qcow2 shouldn't really take more than 15m), though just having one overall timeout to start with will at least prevent jobs from getting stuck anywhere in the process forever and taking up a pod in a cluster. Closes: coreos#195
dustymabe
pushed a commit
that referenced
this issue
Mar 28, 2020
Let's cap build runs to 4h. Builds should never take that long. Ideally, we'd do timeouts per stage, and that could make sense (e.g. signing for example could in the worst case take more than 1h, but building the qcow2 shouldn't really take more than 15m), though just having one overall timeout to start with will at least prevent jobs from getting stuck anywhere in the process forever and taking up a pod in a cluster. Closes: #195
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
E.g. we had a build recently just hang on S3 uploads.
Or could try to be fancier and do different timeouts per stage. But a big wrapping timeout would work to begin with.
The text was updated successfully, but these errors were encountered: