ci(k8s): cap k8s deployment job runtime to stop multi-hour hangs - #15698
Merged
Conversation
The k8s deployment job had no job-level timeout and left several hang-prone steps untimed (minikube bring-up, artifact download, helm dependency update). A stall in any of those fell through to GitHub's 360-minute default job timeout, letting the job burn hours of runner time. Add a job-level timeout-minutes: 30 backstop (a healthy run finishes well under 20 minutes) plus per-step timeouts on the two untimed shell steps most likely to stall. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
blakeaowens
approved these changes
Aug 18, 2026
devGregA
approved these changes
Aug 18, 2026
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
3 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.
[sc-14593]
Problem
The
test-k8sjob (k8s-tests.yml) can run for hours. It had no job-leveltimeout-minutes, and several hang-prone steps were left untimed:Setup Minikube(cluster bring-up), thedownload-artifactstep, andConfigure HELM repos(helm dependency update). When any of those stalls, there is nothing to stop it, so the job falls through to GitHub's 360-minute (6-hour) default job timeout and burns runner time.Fix
timeout-minutes: 30as a hard backstop that catches a hang in any step, including theuses:steps that can't be caught by the existing per-step timeouts. A healthy run finishes well under 20 minutes, so 30 leaves comfortable headroom.Setup Minikube(10 min) andConfigure HELM repos(5 min), so a failure attributes to the right step rather than only tripping the job cap.Both k8s-version matrix cells are capped independently.
No behavior change for a healthy run; this only bounds the failure mode.
🤖 Generated with Claude Code