ci: report-only source-liveness sweep (pkgmgr-rs#447 slice 1) - #530
Conversation
Probe the direct-upstream source URLs — the ones not served from
gs://minimal-staging-archives — and report the ones that 404.
Why it can't ride on `pkgmgr update`: an update run only touches packages
it is attempting to bump, so a package sitting at the latest version never
exercises its source URL. Upstream can delete a tarball and the first
symptom is a build failure during a security bump — precisely when the
source is what you need. Same "drift happens independently of any PR"
logic that gives corresponding-source its weekly cron.
The design decision that matters is what this REFUSES to say. A GitHub
Actions runner's egress differs from the build sandbox's and the Cloud Run
runner's, so only 404/410 is reported as `gone`; 403, 429, 5xx, timeouts
and connect failures are `unknown` — explicitly "we could not tell from
here", never a fault.
The full sweep validates that immediately. 211 distinct URLs across 433
packages:
0 gone · 2 unknown · 0 unresolved · 209 ok
and both unknowns are exactly the predicted class —
libx265 bitbucket.org 403 (blocks HEAD/bot user-agents)
nettle ftpmirror.gnu.org 000 (connect failure; GNU's redirector is
flaky from some egress, which is why
`pkgmgr mirror` has a fallback for it)
Neither is gone. Collapsing non-200 into "broken" would have opened this
report with two false alarms on day one, which is how a report-only check
gets ignored forever.
Also deduplicates by URL before probing (several packages share one
upstream) and discloses any `--limit` truncation in the summary, so a
capped run can't read as full coverage.
Slice 1 only, deliberately: no Rust subcommand, no DomainPacer, no issue
filing, no Cloud Scheduler, no alarm. Eighth sibling of the report-only
family, modeled on corresponding-source.yml. Schedule + manual dispatch
only — PR-triggered probing of arbitrary upstream hosts would add latency
and rate-limit exposure for a signal that moves on upstream's timescale.
REPORT-ONLY. Must not become a required check.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Slice 1 of gominimal/pkgmgr-rs#447. Report-only, non-blocking, eighth sibling of the existing report family — modeled directly on
corresponding-source.yml.Not for merge without review — flagging that explicitly since this adds a scheduled workflow.
What it does
Probes the direct-upstream source URLs (the ones not served from
gs://minimal-staging-archives) and reports the ones that 404.Why this can't ride on
pkgmgr update: an update run only touches packages it's attempting to bump, so a package sitting at the latest version never exercises its source URL. Upstream can delete a tarball and the first symptom is a build failure during a security bump — precisely when the source is the thing you need. Same "drift happens independently of any PR" logic that givescorresponding-sourceits weekly cron.Complementary to that check rather than overlapping: corresponding-source asks "is our copy there", this asks "is upstream's copy still there".
The design decision is what it refuses to say
A GitHub Actions runner's egress differs from the build sandbox's and the Cloud Run runner's. So only 404/410 is reported as
gone. 403, 429, 5xx, timeouts and connect failures areunknown— explicitly "we could not tell from here", never a fault.The full sweep validated that on the first run. 211 distinct URLs across 433 packages:
and both unknowns are exactly the predicted class:
libx265nettlepkgmgr mirroralready carries a fallback for itNeither is gone. Collapsing non-200 into "broken" would have opened this report with two false alarms on day one, which is how a report-only check earns permanent ignoring.
Other care taken
--limittruncation in the summary, so a capped run can't read as full coverage.--proto =https, charset-validated URLs from tracked build.ncl, no secrets, no downloads.workflow_dispatchonly. PR-triggered probing of arbitrary upstream hosts would add per-PR latency and rate-limit exposure for a signal that moves on upstream's timescale, not ours. Tuesday 06:17 UTC, offset from the Monday siblings.Explicitly not in this slice
No Rust subcommand, no DomainPacer, no automatic issue filing, no Cloud Scheduler, no alarm. #447 as filed is 3-4 days of machinery for a signal we've never measured; this measures it first for the cost of one script.
If the weekly report turns up real
gonerows, that's the evidence for building the rest. If it stays at 0/211, that's worth knowing too.🤖 Generated with Claude Code