Repository navigation
feat(ci): Timeout long running actions - #187
Open
spotandjake wants to merge 1 commit into
Open
spotandjake wants to merge 1 commit into
spotandjake wants to merge 1 commit into
Conversation
This pr adds actions timeouts to our ci runs, the motivation for this pr was hangs we are seeing on windows, instead of running for 6 hours and cancelling manually when we notice it makes more sense to just set high upper limits. The idea here is that these are upper limits, we should never be timing out builds except for cases where something has hung. Opam: looking over the recent runs most builds seem to take between 20 and 3- minutes, we give 90 minutes to leave a bit of a buffer (primarly for windows). Esy: looking over the recent runs most builds seem to take between 20 and 90 minutes, we give 120 minutes to leave a bit of a buffer (primarly for windows). JS: Generating binaryen.js bindings is normally quick, and not a place that is problematic, so we leave an upper limit of an hour which gives plenty of time for run to run variance.
Kara-Zor-El
approved these changes
Oct 15, 2026
Kara-Zor-El
left a comment
Kara-Zor-El
left a comment
Member
There was a problem hiding this comment.
Looks good. Still a very long timeout time but why is understandable
Member
Author
They certainly could be reduced, but I'm not trying to prevent abuse, really just against hung runs. The downside of keeping it too low is that if something changes in binaryen that reduces the build times, it could cause failures here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pr adds actions timeouts to our ci runs, the motivation for this pr was hangs we are seeing on windows, instead of running for 6 hours and cancelling manually when we notice it makes more sense to just set high upper limits.
The idea here is that these are upper limits, we should never be timing out builds except for cases where something has hung.
Opam:
looking over the recent runs most builds seem to take between 20 and 3- minutes, we give 90 minutes to leave a bit of a buffer (primarly for windows).
Esy:
looking over the recent runs most builds seem to take between 20 and 90 minutes, we give 120 minutes to leave a bit of a buffer (primarly for windows).
JS:
Generating binaryen.js bindings is normally quick, and not a place that is problematic, so we leave an upper limit of an hour which gives plenty of time for run to run variance.