Repository navigation
CI: set timeout-minutes on every job - #29
Open
ahsanalidotme wants to merge 1 commit into
Open
ahsanalidotme wants to merge 1 commit into
ahsanalidotme wants to merge 1 commit into
Conversation
A stuck job now fails at its timeout instead of holding a runner for the 360-minute default. Timeouts come from recent successful run durations (about 2-3x the p90, with floors for tiny jobs, lint and builds).
ahsanalidotme
marked this pull request as ready for review
October 28, 2026 12:53
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
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.
What
Every job now has a
timeout-minutes, so a stuck job is killed and frees its runner instead of running to GitHub's 360-minute default. (A 5-secondchangesjob recently sat in progress on a self-hosted Mac runner for 4 hours.)How
Added
timeout-minutesto each job that had none, picked from the last 30 successful runs per workflow (durations in minutes,started_attocompleted_atper job). Rule: about 2-3x the p90, rounded up, with floors of 5 min for tiny jobs, 15 for lint/unit and 30 for builds; release/publish jobs get 60-90. No job names, triggers or runners changed.actionlintis clean on every changed file (apart from existing shellcheck style notes on untouchedrun:scripts).ci.ymlchangesci.ymllibraryci.ymlexample-androidios.ymlchangesios.ymliosrelease.ymlpublishProduction impact
Production impact: CI only. Only
.github/workflows/*.ymlchanges; no app, API, SDK or database code is touched. A job that runs longer than its new limit is cancelled, so the numbers leave room over the slowest measured run.Tests
Only workflow files change, so there is no code to test. CI on this PR runs the edited workflows.
Preview
None (CI only).
Details (optional)
A job timeout is enforced by the runner process. If the self-hosted runner itself hangs, the job can still look "in progress" until the runner is restarted.
Links
Same change in every linktrail-io repo, one PR each (branch
ci/job-timeouts).