Repository navigation
ci: add timeouts and fail-fast guards to the workflows - #549
Merged
Merged
Conversation
Every job gets a `timeout-minutes` so a hung step can no longer burn GitHub's 6 hour default, and every step after the first gets an `!cancelled() && steps.<previous>.outcome == 'success'` guard so a failure skips the remaining work instead of running on. Jobs that run V tests also get VTEST_FAIL_FAST=1, which stops the test session after the first failing file (a red suite stays red). No step was added, removed, renamed or reordered, and no `run:` command was touched. Runner images and toolchains are unchanged.
Address review findings on the fail-fast change: - Guards now read `success() && !cancelled() && steps.<prev>.outcome == 'success'`. A bare `!cancelled()` suppresses GitHub's implicit `success()` check, so a failure in a step outside the immediate chain would not have stopped later steps. - A step that already carries a condition of our exact shape gets it replaced in place instead of gaining a second `if:` key, which is invalid workflow syntax. Steps whose condition is anything else (matrix picks, failure reporters such as `steps.x.outcome != 'success'`) keep it and stay out of the chain. - Jobs that call a reusable workflow no longer get `timeout-minutes:` (GitHub forbids it there); the timeouts live on the jobs inside the called workflows instead.
The four guards this branch added were no-ops. GitHub applies a default `success()` check to a step unless the `if` names a status function, and `success()` means every earlier step succeeded, so `success() && !cancelled() && steps.X.outcome == 'success'` can never be false for an `X` that already ran. Each guard, and the `id:` it read, is gone. What actually stops a wedged step is a budget, and there was one only on the two `-prod` runs. Every step now carries its own `timeout-minutes`, sized well above a healthy run: a checkout that hangs on the network fails in ten minutes, and a build or a test that wedges fails at its own budget instead of spending the rest of the job's hour on it. The job-level 60 stays as a backstop that should never fire first. Windows also ran `-prod` without `VLS_VLANG_V_REPO`, which `index_test.v` and `integration_test.v` read to find the vlang/v checkout; without it those tests resolve `vlib` from the installed V while the ubuntu `-prod` run used the checkout, so the two covered different trees. Both now set it. Checked with actionlint 1.7.12 (0 errors). The Windows and macOS jobs are currently red before vls is ever compiled, failing inside vlang/v's own build (`Backend compiler error`, `Compilation of v.c failed`), which this cannot fix.
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.
None of this repository's workflows stop early: a hung step burns GitHub's 6 hour default because no job sets
timeout-minutes, and a failed step still runs every step after it.timeout-minutes(60 minutes generally; higher where the workload justifies it, e.g. benchmark and OS-image jobs).!cancelled() && steps.<previous>.outcome == 'success'guard, so a failure skips the remaining steps instead of spending the rest of the timeout. Steps that already carry their own condition keep it, and are never chained from.VTEST_FAIL_FAST=1, which stops the test session after the first failing file (a red suite stays red).This was applied mechanically and verified as a pure transformation: no step was added, removed, renamed or reordered, no
run:command was touched, and no runner image or toolchain changed. The check suite confirms the step names and everyrun:line are identical to the base, the guard chain of each job is internally consistent, and formatting semantics are unchanged.