CI and Deployment

CI and deployment

What runs on every push, what ships where, and which sweeps report without blocking. The required checks are the gate's; everything else is advisory.

The gate

ci.yml runs on every push and pull request:

1. the library packages' dists, restored from cache or built (tools/ci/dist-cache.ts);
2. vp check;
3. the per-package tests, in shards;
4. the site build.

The dists come first because type-aware lint and the tests resolve sibling packages through dist/. main requires these checks (tests, check + site build), so a change lands through a pull request, never a direct push.

• Only what a change affects. tools/ci/affected.ts selects the packages that own a changed file plus their dependents, through declared dependencies and the ../<pkg>/ paths build scripts read. Shards with nothing selected skip and still report success. A push to main, a dispatch, or a change to the lockfile, root config, .github, tools, engine or ce-patches runs everything. node tools/ci/affected.ts --base <ref> shows the selection locally.
• Cached dists. Each package (or dependency cycle, built as one unit) is keyed by its files, its dependencies' keys and the shared inputs (lockfile, root config, node version). CI saves the cache from main pushes, so PRs restore from main's.

Production and previews

• Production (enumeratio.dev) ships from Cloudflare Pages on merge to main: CI deploys the site artifact with --branch=main, the project's production branch. web/public/_headers gives /vendor/* and the content-hashed /assets/* a year-long immutable cache.
• Every build of every commit, PR pushes and main alike, also goes up as a Cloudflare Pages preview at <sha7>.enumeratio.pages.dev, direct-uploaded from the artifact the gate already built.
• The PR's sticky <!-- cf-preview --> comment carries the URL. Review links go below its first two lines, which each push rewrites; the rest is left alone.
• preview-cleanup.yml runs nightly. It deletes a PR's previews a day after the PR closes, and untagged previews older than 30 days; a tagged commit's preview stays.
• Needs the repo secrets CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID.

Advisory sweeps

None of these is a required check.

• Plausible (plausible.yml, after Lean 4's; see Plausible) samples the collection kernels on every push that touches them, and deeply each night. A failure files or reopens one rolling issue, plausible sampling regression, labelled nightly-fixup.
• Nightly oracle rescans (nightly.yml) check the light oracle lanes against the committed values, one job per ecosystem: Python (mpmath, SymPy), Julia (Nemo, Combinatorics.jl) and Rust (num, primal, statrs, adic).
• Oracle Plausible runs in each of those jobs (reference/scripts/oracle-plausible.ts). It resamples the documented examples toward the edges of each domain, seeded by the date so every job draws the same samples, and checks them against that ecosystem's lanes. What no classified example explains goes to a rolling oracle Plausible findings: <ecosystem> issue for triage.
• Weekly rescans do the same for Oscar, Mathlib, Sage (in Docker, with the adeles and adic goldens) and Wolfram, and follow every crosswalk link. Wolfram runs on an on-demand license, the WOLFRAMSCRIPT_ENTITLEMENTID secret, and skips without it.

How a lane reports:

• It fails when a row it had answered changes verdict, classification or input, not on a float's printed digits.
• A row answered for the first time (a new example the weekly kernels hadn't seen) is a warning.
• Every lane uploads what it accepted as an oracle-records-<system> artifact, so the answers can be applied and classified without the kernel.

Examples too many to render (grid points, edge cases) are still data: role: test examples in the head's examples.tsv, tested and scanned like the rest.

The nightly-fixup routine

At 06:15 UTC a routine reads these runs, files CI failure: <workflow> › <job> issues, and opens fix PRs. It never merges.