Skip to content

ci: cache the test project's installed modules between runs - #58

Merged
Upd4ting merged 2 commits into
mainfrom
ci/cache-test-modules
Nov 7, 2026
Merged

Upd4ting merged 2 commits into
mainfrom
ci/cache-test-modules

Conversation

@Upd4ting

@Upd4ting Upd4ting commented Nov 7, 2026 •

Copy link
Copy Markdown
Member

Why

Goal: make the interface-auth CI and the verify-interface skill as fast as reasonable, measured before and after each fix.

Done means: every fix is measured and lands in its own pull request against main carrying before/after numbers, with the repository checks green and the review gate passed.

The CI test job is the critical path of every run (median 31 s on recent main runs, "Run tests" median 12.5 s). Most of "Run tests" is ajs module test installing the test project's npm modules into .antelope/cache ("Loaded 3 modules 7.3s" on the latest main run). The tests themselves take 27 ms. Those installs also resolve every transitive dependency afresh on each run, because the modules' lockfiles were never recorded ("Recorded 2 module locks in antelope-lock/: commit them so every install gets the same dependencies").

What changed

  • antelope-lock/ is committed. Core replays each recorded lockfile when it installs a module, so every run installs the same dependency graph instead of the newest in range.
  • ci.yml passes cache-paths: .antelope/cache and cache-key-files: src/antelope.test.ts plus antelope-lock/** to ci-node.yml, which restores the folder before the tests and saves it after a miss. Only the Test job writes the folder. The Node job skips tests, so it has nothing to save.
  • AGENTS.md says how antelope-lock/ is used and refreshed.

A restored folder never serves different dependencies than a fresh install. Core reuses a cached module only when the version in its manifest.json satisfies the pinned one and its lockfile is byte-identical to the recorded one; otherwise it reinstalls from the record. Checked by downgrading @antelopejs/interface-api inside a cached api module to 0.1.0: the next pnpm test reinstalled it at the recorded 0.3.0.

Measurements

Local pnpm test on current main (after #57 and #59), 4 interleaved rounds per side, fresh npm cache and pnpm store each round, load 13 to 15 on 16 cores:

CPU user+sys, median wall range
main (no lock, no cache) 11.0 s 5.4 to 6.7 s
lock committed, no cache (a cache miss) 4.5 s 2.9 to 3.1 s
lock committed, cache restored 2.6 s 1.71 to 1.73 s

No wall ranges overlap.

CI, Test job (the critical path) on GitHub runners:

"Run tests" step Test job
main, 4 recent runs 10 to 14 s, median 12.5 s 28 to 33 s, median 31 s
this PR at 141216c (before the rebase onto #57), 2 runs, both restored a cache 5 s and 7 s 20 s and 24 s
main after #57 and #59, 2 runs 7 s and 9 s 19 s and 23 s
this PR at 1d1798e, 1 run 1 s 17 s

In those runs, "Valid module found" to "Loaded 3 modules" took 2.4 s and 3.4 s, against 10.3 s on the latest main run.

Verification

  • pnpm run checks: 8 passed, 0 failed.
  • verify-interface, all four features (antelope-lock/** is a shared file): smoke, tokens, cookies and request-auth journeys all PASS. No one-way door flagged.

@Upd4ting
Upd4ting force-pushed the ci/cache-test-modules branch from 141216c to 1d1798e Compare November 7, 2026 15:58
@Upd4ting
Upd4ting merged commit 7e1e3b5 into main Nov 7, 2026
8 checks passed
@Upd4ting
Upd4ting deleted the ci/cache-test-modules branch November 7, 2026 16:39
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.

1 participant