Skip to content

ci: the nightly capability sweep and upgrade guard install from the build job's apt cache - #1759

Merged
jdatcmd merged 1 commit into
mainfrom
ci/nightly-sweep-guard-apt-cache
Oct 26, 2026
Merged

jdatcmd merged 1 commit into
mainfrom
ci/nightly-sweep-guard-apt-cache

Conversation

@OffgridwithJD

Copy link
Copy Markdown
Collaborator

@jdatcmd Follow-up to #1758 for #1757. Run 40367661645 (your #1758 verification dispatch) still went red on one job: capability name-set sweep (PG 18), at its install step, all three 200-second apt-get install attempts stalled on the Azure mirror. It's the same cause as its red on 2026-10-23 (run 39944578717). The product never ran.

Change: capability-sweep and upgrade-guard are the two remaining PG 18 nightly jobs that download ~100 MB uncached, mostly the LLVM toolchain postgresql-server-dev-18 depends on. Both now restore the newest apt-pgdev-codecs-pg18- archive read-only and install with -o Dir::Cache::archives=$HOME/apt-archives. That is #1758's pattern verbatim: no key derivation, no save, and a miss falls back to the full download.

Not changed: sanitizer also installs uncached, but its package set is clang plus build tools, not PGDG. No existing cache matches it, so it would need its own saved key. I left it out of scope.

Evidence

  • NO_CLUSTER guards: 839 passed (accounting: 2186 pass + 0 fail).
  • YAML parses.
  • nightly.yml is dispatched on this branch, run 40376459928. I'll post the two jobs' install times and Get: counts when it finishes.

No test, ledger or census files are touched, so this conflicts with nothing in your #1736…#1751 stack.

🤖 Generated with Claude Code

…uild job's apt cache

#1758 seeded the nightly cluster-test job from ci.yml's build-job apt archive.
Two PG 18 jobs still downloaded ~100 MB uncached, most of it the LLVM toolchain
postgresql-server-dev-18 pulls in. The capability sweep lost all three
200-second install attempts to a stalled Azure mirror twice: 2026-10-23 (run
39944578717) and 2026-10-26 (run 40367661645, the one that kept #1757 open after
#1758). The extension upgrade guard installs the same packages and has the same
exposure.

Both jobs now restore the newest archive under apt-pgdev-codecs-pg18-, read-only,
and install with it as apt's archive cache, exactly as #1758 does. They derive no
key and never save, and a miss falls back to the full download.

Guards: 839 passed. Verified by dispatching nightly.yml on this branch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@jdatcmd jdatcmd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved on 70bb7cb. The change is #1758's restore step applied to upgrade-guard and capability-sweep: same read-only prefix, same -o Dir::Cache::archives, and partial/ created first. Your dispatch on this branch (run 40376459928) shows it working on both jobs:

extension upgrade guard (PG 18)    success  Cache restored from key: apt-pgdev-codecs-pg18-Linux-X64-96a18ef3fcc4-v3  Need to get 0 B/103 MB
capability name-set sweep (PG 18)  success  Cache restored from key: apt-pgdev-codecs-pg18-Linux-X64-96a18ef3fcc4-v3  Need to get 0 B/103 MB

Leaving sanitizer out is right: no existing archive matches its package set, so it would need its own saved key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants