ci: add missing timeout-minutes guards to hot-path jobs #122

Merged

admin merged 1 commits from ci/timeout-guards-0pt-20260927 into main 2026-09-27 01:50:05 +00:00

Conversation 1 Commits 1 Files Changed 5

+7

admin commented 2026-09-27 01:46:40 +00:00

Owner

Copy Link

Copy Source

Part of a fleet-wide CI-speed audit (timeout-minutes + duplicate-trigger pass).

What changed

Added job-level timeout-minutes to every job in a push/pull_request-triggered workflow that was missing one, sized to what the job actually does:

File	Job	timeout-minutes	Why
cd.yml	deploy	20	bounded ~10min signed-artifact poll + setup/verify steps
ci.yml	quality	30	typecheck + vitest + next build
ci.yml	integration	45	multi-service: live OpenSearch + ClickHouse containers
ci.yml	security	15	single trivy fs scan
security.yml	security	15	single trivy fs scan
masterplan-lock.yml	check	10	single dependency-free shell check
release.yml	release	45	docker build/push + full G17 SBOM/scan/attest/verify chain

No job that already had timeout-minutes was touched. .gitea/workflows/vehiq-oltp-ingest.yml, health-check.yml and nightly.yml were left alone (schedule/workflow_dispatch-only, not on the hot path — and the first is out of scope entirely per this pass's rules).

What I deliberately did NOT change

ci.yml, security.yml and masterplan-lock.yml all trigger on both unfiltered push and pull_request, which is normally this pass's second target (fix via adding a concurrency: block). I left that out here on purpose:

ci.yml's own integration job carries a dated comment stating, measured live on this fleet (runs 28904/28906), that "Gitea currently ignores workflow concurrency" — a branch push followed by its PR synchronize event still starts two full sets of service containers regardless of any concurrency: block. This repo's actual fix for that (self-identifying OpenSearch/ClickHouse containers, verified by run-unique identity) is already in place for the one job where it mattered enough to be worth the complexity.

Adding a concurrency: block on top of that would be, per this repo's own evidence, inert boilerplate at best — and at worst it reintroduces a known failure mode: repo memory from this same fleet-wide pass (measured in admin/serv0, 2026-09-26) shows this exact push+pull_request + concurrency-group combination producing PRs that go red with zero failing tests — the queued duplicate run gets cancelled by Gitea before a runner ever picks it up, and posts as a red commit status indistinguishable from a real failure. That measurement was taken in one of the very repos cited elsewhere as the working pattern for this fix, so I'd rather flag the conflict than propagate it here without a human decision.

Given that, and per this pass's own instruction not to touch on: triggers, I left the double-trigger question open for 0pt rather than adding a guard I have concrete, in-repo and fleet evidence is not a real fix on this Gitea version. Happy to revisit once that's resolved fleet-wide.

Validation

Every edited file re-parses with python3 -c "import yaml; yaml.safe_load(open(...))" — clean, all 5 OK. Diff is 7 insertions across 5 files, nothing else touched.

🤖 Generated with Claude Code

Part of a fleet-wide CI-speed audit (timeout-minutes + duplicate-trigger pass). ## What changed Added job-level `timeout-minutes` to every job in a push/pull_request-triggered workflow that was missing one, sized to what the job actually does: | File | Job | timeout-minutes | Why | |---|---|---|---| | `cd.yml` | `deploy` | 20 | bounded ~10min signed-artifact poll + setup/verify steps | | `ci.yml` | `quality` | 30 | typecheck + vitest + next build | | `ci.yml` | `integration` | 45 | multi-service: live OpenSearch + ClickHouse containers | | `ci.yml` | `security` | 15 | single trivy fs scan | | `security.yml` | `security` | 15 | single trivy fs scan | | `masterplan-lock.yml` | `check` | 10 | single dependency-free shell check | | `release.yml` | `release` | 45 | docker build/push + full G17 SBOM/scan/attest/verify chain | No job that already had `timeout-minutes` was touched. `.gitea/workflows/vehiq-oltp-ingest.yml`, `health-check.yml` and `nightly.yml` were left alone (schedule/workflow_dispatch-only, not on the hot path — and the first is out of scope entirely per this pass's rules). ## What I deliberately did NOT change `ci.yml`, `security.yml` and `masterplan-lock.yml` all trigger on both unfiltered `push` and `pull_request`, which is normally this pass's second target (fix via adding a `concurrency:` block). I left that out here on purpose: `ci.yml`'s own `integration` job carries a dated comment stating, measured live on this fleet (runs 28904/28906), that **"Gitea currently ignores workflow concurrency"** — a branch push followed by its PR synchronize event still starts two full sets of service containers regardless of any `concurrency:` block. This repo's actual fix for that (self-identifying OpenSearch/ClickHouse containers, verified by run-unique identity) is already in place for the one job where it mattered enough to be worth the complexity. Adding a `concurrency:` block on top of that would be, per this repo's own evidence, inert boilerplate at best — and at worst it reintroduces a known failure mode: repo memory from this same fleet-wide pass (measured in `admin/serv0`, 2026-09-26) shows this exact `push`+`pull_request` + concurrency-group combination producing PRs that go red with **zero failing tests** — the queued duplicate run gets cancelled by Gitea before a runner ever picks it up, and posts as a red commit status indistinguishable from a real failure. That measurement was taken in one of the very repos cited elsewhere as the working pattern for this fix, so I'd rather flag the conflict than propagate it here without a human decision. Given that, and per this pass's own instruction not to touch `on:` triggers, I left the double-trigger question open for `0pt` rather than adding a guard I have concrete, in-repo and fleet evidence is not a real fix on this Gitea version. Happy to revisit once that's resolved fleet-wide. ## Validation Every edited file re-parses with `python3 -c "import yaml; yaml.safe_load(open(...))"` — clean, all 5 OK. Diff is 7 insertions across 5 files, nothing else touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

admin added 1 commit 2026-09-27 01:46:40 +00:00

chore(ci): add missing timeout-minutes guards to hot-path jobs ... 4c47e151f3

Fleet-wide CI-speed pass: none of 0pt's push/pull_request-triggered
workflow jobs capped their own runtime, so a hang (network stall,
runaway process, stuck polling loop) burns a runner slot until Gitea's
own default kicks in. Added job-level timeout-minutes sized to what
each job actually does:

  cd.yml            deploy      20  (bounded ~10min signed-artifact poll + setup)
  ci.yml            quality     30  (typecheck/test/build)
  ci.yml            integration 45  (multi-service: live OpenSearch + ClickHouse)
  ci.yml            security    15  (single trivy fs scan)
  security.yml      security    15  (single trivy fs scan)
  masterplan-lock.yml check     10  (single dependency-free shell check)
  release.yml       release     45  (docker build/push + full G17 SBOM/scan/attest/verify chain)

Deliberately NOT included in this PR: a concurrency: block for
ci.yml/security.yml/masterplan-lock.yml's push+pull_request double-
trigger. ci.yml's own `integration` job comment already documents,
measured live (runs 28904/28906), that "Gitea currently ignores
workflow concurrency" on this fleet, and the repo's real fix for the
resulting double-run-on-shared-service-containers problem is the
self-identifying-container pattern already in that job, not a
concurrency group. Adding an inert concurrency: block here would give
false confidence that the duplicate-run problem is handled when it
measurably is not. Left for a follow-up decision once that fleet-wide
finding is resolved.

Part of a fleet-wide CI-speed pass (timeout-minutes audit).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CODEOWNERS rules requested review from sax3l 2026-09-27 01:46:40 +00:00

siax-bot approved these changes 2026-09-27 01:46:47 +00:00

siax-bot left a comment

Collaborator

Copy Link

Copy Source

Fleet-wide CI-speed pass: timeout-minutes guards added to hot-path jobs. Concurrency-block fix deliberately skipped for this repo — see PR body for the in-repo + fleet-memory evidence against it.

Fleet-wide CI-speed pass: timeout-minutes guards added to hot-path jobs. Concurrency-block fix deliberately skipped for this repo — see PR body for the in-repo + fleet-memory evidence against it.

admin merged commit 67ee239c84 into main 2026-09-27 01:50:05 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

sax3l

siax-bot

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

siax-bot siax-ci siax-healer (siax-healer (CI self-healing agent)) admin (Simon Axelsson)

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: admin/0pt#122