FluidNumerics / FluidNumerics/SELF

CI: debug and coverage jobs exceed the 90-minute workflow timeout

Open
#157 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Fortran
Stars
92
Forks
13
Avg merge
20h 38m
Merged PRs (30d)
7

Description

# Observed

On PR #156 (head `d25c365`, workflow `linux-gnu-cmake.yml`), the release matrix is comfortable but the debug/coverage matrix is at or over the `timeout-minutes: 90` ceiling:

| Job | Result | Duration |
| --- | --- | --- |
| gfortran-9 / 10 / 11 / 12 — release | ✅ success | 10–13 min |
| gfortran-10 — debug | ✅ success | **67 min** |
| gfortran-9 — debug | ❌ cancelled (timeout) | 90 min |
| gfortran-11 — debug | ❌ cancelled (timeout) | 90 min |
| gfortran-12 — coverage | ❌ cancelled (timeout) | 90 min |

That one debug job passed at 67 min while its siblings hit 90 min suggests the suite is right at the edge and runner variance decides the outcome.

# Why

- Debug builds (`-O0` + runtime checks) run the full ctest suite — which includes every registered **example** — roughly 5–10× slower than release; coverage adds gcov instrumentation on top.
- The suite's cost has grown steadily with new tests and examples. PR #156 added two AMR example smoke runs that are cheap in release (~1 min and ~3 min) but expensive in debug; that branch is being slimmed (smaller default epoch counts) as immediate mitigation. But the 67-minute pre-existing debug baseline means the margin was nearly gone before it.

# Options (not mutually exclusive)

1. **Exclude examples from debug/coverage ctest runs.** Examples validate behavior in release; their debug value is low relative to the targeted tests. PR #156 adds a CTest `example` label to everything registered by `examples/CMakeLists.txt`, so workflows can opt out with `ctest -LE example` in the debug/coverage matrix entries — a one-line workflow change, no test deletion.
2. **Per-test budget**: pass `ctest --timeout ` so a single runaway test fails fast instead of consuming the whole job.
3. **Raise `timeout-minutes`** — quick, but hides suite growth and burns runner minutes.
4. **Move debug/coverage to a scheduled (nightly) workflow** instead of per-PR, keeping release + fprettify as the PR gate.

Happy to implement whichever combination the maintainers prefer.

Contributor guide

Open the contributing guide

Research direction

Start with linux-gnu-cmake.yml and examples/CMakeLists.txt, then inspect the ctest commands used by the debug and coverage matrix entries. Compare the available mitigation options and confirm the chosen change keeps the affected jobs within the 90-minute timeout without removing tests from release runs.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, fortran, github-actions
Domain
build-system, ci-cd, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.