Repository navigation
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.
medvednikov
left a comment
medvednikov
left a comment
There was a problem hiding this comment.
Correctness blocker when combined with #294: the -prod step (and subsequent CSS/tests) is gated on steps.compile_gitly_with_autofree.outcome == 'success'. #294 makes that -autofree step continue-on-error: true; on failure, GitHub records outcome: failure but conclusion: success. Your extra gate will then skip -prod and everything downstream while the job can appear green. Prefer removing the previous-step .outcome chains entirely—GitHub's default success() behavior already skips steps after hard failures—or gate on the effective .conclusion if needed. Separately, the PR description says test jobs receive VTEST_FAIL_FAST=1, but the actual diff contains no such setting; either add it or correct the description. The job timeouts themselves are a useful change.
|
Done - addressed in the latest push. |
None of this repository's workflows stop early: a hung step burns GitHub's 6 hour default because no job sets \ imeout-minutes, and a failed step still runs every step after it.
This was applied mechanically and verified as a pure transformation: no step was added, removed, renamed or reordered, no
un:\ command was touched, and no runner image or toolchain changed.