Repository navigation
ci: cache the test project's installed modules between runs - #58
Merged
Merged
Conversation
Upd4ting
force-pushed
the
ci/cache-test-modules
branch
from
November 7, 2026 15:58
141216c to
1d1798e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
maincarrying 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
mainruns, "Run tests" median 12.5 s). Most of "Run tests" isajs module testinstalling the test project's npm modules into.antelope/cache("Loaded 3 modules 7.3s" on the latestmainrun). 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.ymlpassescache-paths: .antelope/cacheandcache-key-files: src/antelope.test.tsplusantelope-lock/**toci-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.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.jsonsatisfies the pinned one and its lockfile is byte-identical to the recorded one; otherwise it reinstalls from the record. Checked by downgrading@antelopejs/interface-apiinside a cachedapimodule to 0.1.0: the nextpnpm testreinstalled it at the recorded 0.3.0.Measurements
Local
pnpm teston currentmain(after #57 and #59), 4 interleaved rounds per side, fresh npm cache and pnpm store each round, load 13 to 15 on 16 cores:main(no lock, no cache)No wall ranges overlap.
CI, Test job (the critical path) on GitHub runners:
main, 4 recent runsmainafter #57 and #59, 2 runsIn those runs, "Valid module found" to "Loaded 3 modules" took 2.4 s and 3.4 s, against 10.3 s on the latest
mainrun.Verification
pnpm run checks: 8 passed, 0 failed.antelope-lock/**is a shared file): smoke, tokens, cookies and request-auth journeys all PASS. No one-way door flagged.