Profiled the 23s hook step per hook. It is not evenly spread: mypy ~10s and
pylint ~9s are the whole of it, and the remaining 21 hooks share ~4s. Local
timings with a warm cache put mypy at 0.25s against 5.7s cold, so nearly all
of its CI cost is re-analysing the stdlib and third-party stubs from scratch
into a 19MB cache dir that was then thrown away.
Keyed on the config rather than on the sources. The mypy cache metadata
already records the interpreter, the flag set and a hash per source file, so
mypy re-checks whatever actually changed and a restored cache cannot let
stale code pass. The config hash is in the key regardless, so bumping the
mypy rev or editing its args busts it.
Deliberately not keyed on github.sha, which is the other common pattern:
that re-saves 19MB x3 on every commit and would evict the 68MB hook caches
under the 10GB LRU budget for the repo. A fixed key keeps the dependency
analysis, which is the part that costs the 10s.
pylint needs no change -- it already runs --jobs=4.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019kMvSMtsVMB3d2uoZ56pbp
Two follow-ups measured on the warm-cache run of d56b936, where the three
pre-commit jobs were 39-44s split as: 4s runner setup, 9s pip, 2s cache
restore, 23s hooks.
The 9s pip was pure waste. Every linting hook runs in its own isolated env
-- ruff, mypy, pylint, bandit and codespell each come from their own
repo+rev, mypy and pylint declaring their own additional_dependencies -- and
the only local hooks in the pre-commit stage need bash and python3. The
pytest-coverage hook, the one thing that would need the real dependency set,
is stages: [pre-push] and never runs here. Verified by running all three
configs green in a venv containing pre-commit and nothing else. The pin is
grepped out of requirements.txt so it cannot drift from the
dependency-freshness gate.
restore-keys is added because the exact key includes the config hash, so the
next hook-rev bump -- this session did one -- would have been a total miss
and reinstalled everything. A prefix hit rebuilds only the changed hook.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019kMvSMtsVMB3d2uoZ56pbp
Measured on 6154dc0: the three pre-commit jobs took 41-59s, of which 38-49s
was pre-commit installing hook environments and ~11s was an uncached pip.
The cache was not merely cold, it was miskeyed. pre-commit/action@v3.0.1
keys on hashFiles('.pre-commit-config.yaml') -- the repo ROOT's config --
but the hooks it installs come from the per-package config passed in
extra_args. Four different configs, one cache key: the three package jobs
raced to overwrite each other's hook sets, and editing a per-package config
never invalidated the key, so the restored cache was silently wrong rather
than missing. Three 68MB entries in the cache list are the symptom.
So the action is replaced with a direct `pre-commit run`, which keeps the
same --config/--all-files behaviour plus --show-diff-on-failure, wrapped in
an actions/cache keyed on the config that actually drives the install.
pre-commit is already an exact pin in each requirements.txt.
setup-python gains cache: pip keyed on each requirements.txt, for the test
jobs too.
The two crdt-sync workflows now list their own file in `paths`, which the
other four already did -- a workflow edit should re-run its own gate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019kMvSMtsVMB3d2uoZ56pbp
