* CI: give every job an explicit timeout-minutes - #11
Merged
Conversation
Jobs without timeout-minutes inherit the GitHub default of 6 hours, so a wedged test or a hung screenshot capture occupies a runner for that long and queues everything behind it. Sizes come from the observed durations of successful runs, at roughly 2-2.5x each job's maximum with a floor of 15 minutes so a slow runner does not trip them. Jobs that delegate through `uses:` are left alone; a reusable-workflow call cannot carry timeout-minutes, the limit belongs on the jobs inside the called workflow.
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
1 participant
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.
Every job in this repository inherited GitHub's default 6-hour limit. A wedged
test or a hung screenshot capture therefore holds a runner for six hours and
queues everything behind it. This adds an explicit
timeout-minutesto each job.Sizes are taken from the durations of successful runs (job execution time, not
run wall-clock), at roughly 2-2.5x the observed maximum with a floor of 15
minutes so a slow runner does not trip them. Every job here finishes well under
four minutes, so the floor applies throughout.
_build.ymlbuild-exe_build.ymlpack-nugetci.ymlscreenshotsgenerate.ymlscreenshotsnightly.ymlmetanightly.ymlpublishnightly.ymlprunerelease.ymlversionrelease.ymlpublish-githubrelease.ymlpublish-nugetFour jobs are deliberately untouched, because a reusable-workflow call cannot
carry
timeout-minutes- the limit has to sit on the jobs inside the calledworkflow:
ci.yml/ci,nightly.yml/build,release.yml/test,release.yml/build.Note that
ci.yml/cidelegates toHawkynt/RepositoryTemplate/.github/workflows/dotnet-ci.yml@v1,so the actual test and coverage jobs are still unbounded and can only be capped
in
RepositoryTemplate.