Repository navigation
ci: a sysmon check, not a 30-minute cap, catches the coverage fallback - #771
Merged
Merged
Conversation
#770 cut the coverage job's timeout to 30 minutes so that a fallback to the C tracer (~40 min) would fail instead of only slowing CI. GitHub enforces that timeout server-side, and on 8d8c64b it cancelled a run whose 30500 tests and coverage gates had passed at 21 minutes, after GitHub stopped registering the job's step updates. 45 minutes leaves room for that lag. The fallback is caught by a step instead: coverage.py's --debug=core logs the core it would use, and the step fails in a second unless it is sysmon. Same COVERAGE_CORE and [tool.coverage.run] config as the run.
github-actions
Bot
added
ci
📄 Documentation ReminderThis PR appears to be missing a documentation reference. Our docs live in a separate repo. Please update the PR description with one of:
See the Contributing Guide for details. |
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
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.
What
The coverage job's timeout goes back from 30 to 45 minutes, and a new step fails the job in about a second when coverage.py would not measure with
sys.monitoring.Why
#770 set 30 minutes so that a silent fallback to the C tracer (~40 min) would fail instead of only slowing CI. GitHub enforces a job timeout server-side. On
mainat 8d8c64b the job's log shows30500 passed, 1055 skipped ... in 1167.54s (0:19:27), every coverage gate passing, and the Codecov upload and post-job cleanup done at 17:45:51. GitHub never registered those step updates and cancelled the job at 17:54:36 for exceeding 30 minutes. A Test job in the same run lagged the same way: its log ended at 17:44:24 and its completion registered at 17:48:55. The job itself takes 12–22 minutes, so 45 leaves room for the lag.The fallback check moves to where it can be exact. coverage.py's
--debug=core(since 7.4.2, coveragepy/coveragepy#1747) logsUsing core=sysmonorUsing core=ctrace. The new step runs a one-line script under this job'sCOVERAGE_COREand[tool.coverage.run]config, the inputs pytest-cov's core choice depends on.Validation
The step's script, extracted from the YAML and run under
bash -e:Using core=sysmondynamic_context = test_functionUsing core=ctrace, error annotationUsing core=ctraceactionlintis clean and the changed-files detect-secrets hook passes. This PR's own Coverage job runs the new step.Security: CI config only. No new action, permission, secret or expression interpolation.
The cancelled run on
mainwas re-run (failed jobs only).