Author	SHA1	Message	Date
pat-s	8140702b5f	chore(alpine): drop the deprecated Alpine 3.22 slot ... Alpine 3.22 is deprecated and is no longer a published slot. It was never routed: `local.rpkgs_slots` in `cdn.tf` lists eight distros and alpine322 is not among them, so `UNION_SLOTS` never gated per-minor rewriting for it and every request fell through to the flat index. The fleet-wide routing verification made that concrete. Across all 16 published slots, both architectures, three R minors and both contractual URL forms, 1056 of 1056 install-and-load checks passed. Every failure in the run was alpine322, identical on amd64 and arm64, and identical across `arch`, `generic` and `flat`. That last part is the signature of an unrouted slot: on a routed slot the contractual forms diverge from `flat`, because the divergence is the routing. Its flat objects are R 4.5 builds, so R 4.4 and R 4.6 clients got `LOAD_FAILED` while R 4.5 clients were fine. This change will: - Remove the alpine-322 matrix rows and dropdown options from every pipeline that carried them, so `=all` no longer fans out to a slot nobody can reach. - Remove `3.22` from the `OS_VERSION` dropdowns in `build-all-versions.yaml` and `repair-built-stamp.yaml`, and move the latter's default to `3.23`. - Update the stale `3.22` examples in `local/packages-to-build.R`. The six alpine-322 cron jobs are deleted from the Crow server as well, since a cron whose matrix row is gone would keep firing against nothing: 5 process-cran-updates-alpine-322-amd64 0 5/8 * * * 6 process-cran-updates-alpine-322-arm64 30 5/8 * * * 68 weekly-audit-missing-alpine-322-amd64 20 0 * * 0 69 weekly-audit-missing-alpine-322-arm64 30 0 * * 0 82 weekly-rebuild-missing-alpine-322-amd64 0 4 * * 0 83 weekly-rebuild-missing-alpine-322-arm64 10 4 * * 0 The published objects and indexes under `amd64/alpine322` and `arm64/alpine322` are left in place; removing them from the bucket is a separate decision.	2026-09-11 07:25:21 +00:00
pat-s	f3984f337d	fix(ci): authenticate uvr's GitHub resolution in the index workflows (#204) ... ## Why The post-backfill re-index (12257) reported failure. Five slots could not write their indexes: ``` WARN Failed to fetch git Remote pat-s/cranlike@s3 (GitHub API error: 403 Forbidden); falling back to registry resolution ! Attempt 1/3 to update PACKAGES failed (unused argument (built = built)). Retrying in 5s... Error: Failed to update PACKAGES after 3 attempts. Last error: unused argument (built = built) ``` uvr resolves bincraft's dependencies through the GitHub API, including the `pat-s/cranlike@s3` fork. Unauthenticated, that is rate limited. uvr does not fail on the 403 — it **warns and falls back to the registry copy of cranlike**, which has no `built` parameter, so `update_PACKAGES(built = ...)` dies three retries later. Affected: alpine323, rhel8, rhel9, rhel10, noble. The remaining 13 slots resolved the fork fine and indexed correctly, which is what makes this insidious: the same pipeline passes or fails on identical input depending on the rate-limit window. `build-all-versions.yaml` and `rebuild-abi-gap.yaml` already pass `GITHUB_PAT`, which is why they were never affected. ## What changed Adds the `GITHUB_PAT` secret to `reindex.yaml`, `weekly-rebuild-reindex.yaml` and `backfill-flat-safety.yaml`, with a comment recording why its absence is quiet rather than loud. `crow lint` passes on all three. ## Context The re-index itself did what it was meant to. Drops per per-minor index fell from ~1800-2200 to: ``` 4.4: avg 129 4.5: avg 172 4.6: avg 145 ``` so the per-object safety verdicts recovered roughly 93% of the coverage while still dropping every object that genuinely cannot load. This PR is about the five slots that never got to apply it. Reviewed-on: #204	2026-09-05 15:59:16 +00:00
pat-s	e1114bc145	fix(ci): give the index writers the metadata database password (#201) ... ## Why Pipeline 12207 logs one of these per slot: ``` Error: connection to server at "r-binaries.devxy.io" (116.203.165.191), port 15432 failed: fe_sendauth: no password supplied ``` bincraft's index build calls `abi_cache_risky_packages()` to decide which packages may be carried from the flat slot into a per-minor index. `reindex.yaml` and `weekly-rebuild-reindex.yaml` never passed `PGPASS`, so the query cannot connect. It fails soft by design, which is what makes this worth fixing rather than tolerating: the run still reports **success** while using an empty cache-derived risky set. The index is then written as though no package were known risky from the classifier, which is the exact state the cache was added to fix. `build-all-versions.yaml` already passes `PGPASS`, which is why classification behaved correctly there and silently degraded here. ## What changed Adds the `PGPASS` secret to both index-writing workflows, with a comment explaining why its absence is invisible rather than loud. `crow lint` passes on both files. ## Note The tarball-derived half of the risky set still worked, so indexes written without this are not wrong so much as incomplete: they miss packages that are known risky from classification but have no per-minor tarball yet. A re-index after this merges applies the full set. Reviewed-on: #201	2026-09-04 19:26:55 +00:00
pat-s	a2923bf063	fix(cdn): purge the staging zone too (#181) ... ## Motivation `cran-rpkgs-test` was added as a second pull zone on the same B2 origin, but it was never added to `BUNNY_PULLZONES`. It therefore keeps serving pre-reindex indexes behind the same ~370 day `cache_expiration_time` as production, and nothing ever refreshes it. That is not cosmetic. The zone exists to be measured, and a verification run against it measures whatever the edge still holds: ``` production: regressions=0 AGHmatrix Path=NA Built=R 4.5.3; x86_64-pc staging : regressions=161 AGHmatrix Path=4.5 Built=(none) ``` Same objects, same origin, 161 phantom regressions. I chased that number through two wrong diagnoses before noticing production and staging disagreed. ## Change Add `cran-rpkgs-test.b-cdn.net` to the purge list in both reindex pipelines. ## Note A `Cache-Control: no-cache` request header is not a substitute. It was added to the verification script and did **not** clear this: bunny does not honour it for these objects. Purging is the mechanism that works. Reviewed-on: #181	2026-08-31 10:31:35 +00:00
pat-s	f3077677d7	ci: add a reindex-only manual workflow (#177) ... ## Motivation `weekly-rebuild-reindex` exists to run after `weekly-rebuild-missing`: it declares `depends_on: weekly-rebuild-missing` and is gated on that workflow's `weekly_rebuild_missing` variable. Triggering it manually therefore also starts hours of package rebuilds. That is the wrong tool when only the index needs regenerating. After rpkgs/bincraft#113 (v5.1.5), which changes how `union_index_records()` decides what a per-minor index steers to, every object in the bucket is already correct and only `PACKAGES*` is stale. Rebuilding to fix an index is pure waste, and the natural cron would take a full cycle to reach every slot. ## Change Adds `.crow/reindex.yaml`: the index half on its own, manual only, no dependency on a rebuild. It reuses the same matrix and the same steps as `weekly-rebuild-reindex` — install the latest bincraft release, republish the generic index, loop the installed R versions republishing each per-minor index, purge the edge. No package is built. Gated on a new `reindex` variable so it cannot be started by the rebuild gate, defaulting to `none` so a manual pipeline creation (which instantiates every file in `.crow/`) matches no matrix row. ```sh crow pipeline create devxy/build-cran-binaries --var reindex=all crow pipeline create devxy/build-cran-binaries --var reindex=ubuntu-2404-amd64 ``` ## Verification - `crow lint .crow/` passes. - Gate is manual-only and evaluates `reindex`, with no `depends_on` and no `runs_on` carried over from the rebuild coupling. Reviewed-on: #177	2026-08-31 09:55:30 +00:00