Repository navigation
ci: verify binary-release and scheduled MSRV timeout headroom #125
Description
Follow-up to #99 / #111. The timeout configuration is merged and static checks passed, but two runtime acceptance checks require future events.
Already verified:
- All six PR CI checks passed.
- The edited fresh-resolution workflow passed via workflow_dispatch on the feature branch in 78 seconds: https://github.com/rust-works/patchcov/actions/runs/37878298461 .
- The release workflow on ci: set timeouts on release and fresh MSRV jobs #111's merge commit passed: Release took 9 seconds and Release PR took 75 seconds, both well inside their 30-minute limits: https://github.com/rust-works/patchcov/actions/runs/37880424371 . Binary builds were skipped because no release was created.
Remaining verification
- At the next normal version release, inspect every binary matrix leg (Linux x86_64/arm64, macOS x86_64/arm64, Windows x86_64). Confirm each succeeds comfortably within the new 20-minute limit; record run URL and per-job durations.
- After the first scheduled MSRV fresh-resolution run on main (Mondays at 05:17 UTC), confirm the schedule actually fires and the unlocked install succeeds comfortably within its 15-minute limit. Record run URL and job duration. The existing manual branch run proves the steps, not the scheduled event.
Acceptance
Both event types have successful run evidence recorded here. If a legitimate job approaches or exceeds its limit, investigate and propose a measured adjustment separately; distinguish dependency/build failures from timeout failures.
Low priority; observation only unless evidence shows a problem. Use the next normal release and schedule—do not publish a version solely for this check. No known code defects or skipped review findings remain from #111.
Activity
newhoggy commentedon Oct 9, 2026
Implementation plan
Goal and acceptance criteria
Record successful runtime evidence for all five binary-release matrix legs under their 20-minute timeout and an actual scheduled fresh-resolution MSRV run on main under its 15-minute timeout. Use the next normal release and schedule; do not publish a version solely for verification.
Approach and evidence
This is an observation-only follow-up to #99 / #111, with no known code defect. Read both linked items, the current workflows, CONTRIBUTING.md, and docs/RELEASE.md. Inspect GitHub Actions events and per-job timestamps, distinguishing skipped binary builds and manual dispatches from the required events. Static validation or another manual run cannot satisfy the remaining acceptance criteria, so neither workflow edits nor an artificial release are justified.
Checked all four Release runs from #111's merge through current main on 2026-10-09:
The fresh-resolution workflow has only the already-recorded successful workflow_dispatch run on the #99 feature branch. No scheduled run exists yet. The first Monday schedule after #111's merge is 2026-10-12 at 05:17 UTC (16:17 Australia/Sydney); actual execution may be delayed.
Changes, in order
Tests and verification
From the explicit issue-125 worktree:
gh run list --workflow release-plz.yml --limit 20 --json databaseId,event,headSha,createdAt,conclusion,urlgh api 'repos/rust-works/patchcov/actions/runs/<id>/jobs?per_page=100'for each post-merge release run; compute completed_at minus started_at, inspect conclusions and all five actual matrix targets.gh run list --workflow msrv-fresh.yml --limit 20 --json databaseId,event,headBranch,createdAt,conclusion,urlgh run view <scheduled-id> --json jobsand inspect the install-step log for unlocked resolution on the MSRV.git -C /Users/jky/wrk/work-trees/patchcov/issue-125-ci-binary-release-msrv-timeout-headroom status --porcelainto confirm no repository edits.Run the relevant repository checks only if an evidenced implementation change becomes necessary. Application tests and static workflow checks cannot establish that these future events occurred.
Risks, assumptions and out of scope
Both required event types remain pending as of this inspection. Successful no-op Release runs do not prove binary timeout headroom. A manual dispatch does not prove the schedule fires. No release publishing, schedule/trigger changes, timeout changes without evidence, unrelated issue changes, merging, or manual issue closure. There is presently no repository diff to commit, review, rebase, or submit as a PR; #125 stays open until both runtime acceptance checks have evidence. Future event inspection is pending work, not an automation configured by this comment.
newhoggy commentedon Oct 9, 2026
Binary-release acceptance verified
The normal v0.4.0 release followed #43's queue merge on 2026-10-09. All five binary jobs succeeded in https://github.com/rust-works/patchcov/actions/runs/37898722664 using the 20-minute job timeout:
Durations are completed_at minus started_at from the Actions jobs API, excluding queue time. All five archives and their SHA-256 files are attached to https://github.com/rust-works/patchcov/releases/tag/v0.4.0 . The slowest job used 6.7% of its limit; no timeout adjustment is indicated.
The binary-release half of acceptance is complete. The actual scheduled fresh-resolution MSRV run on main remains to be verified; leave #125 open pending that evidence.