mirror of
https://github.com/kuhyx/utils.git
synced 2026-11-10 22:47:14 +01:00
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
57 lines
2.6 KiB
YAML
57 lines
2.6 KiB
YAML
name: gatelock pre-commit
|
|
|
|
on:
|
|
push:
|
|
branches: [main]
|
|
# The workflow's own file counts as gatelock: editing only this file used
|
|
# to trigger nothing, so a fix to the job itself could never prove itself.
|
|
paths: ['gatelock/**', '.github/workflows/gatelock-precommit.yml']
|
|
pull_request:
|
|
branches: [main]
|
|
paths: ['gatelock/**', '.github/workflows/gatelock-precommit.yml']
|
|
|
|
jobs:
|
|
pre-commit:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
- uses: actions/setup-python@v5
|
|
with:
|
|
python-version: "3.x"
|
|
# Only pre-commit itself. Every linting hook runs in its own isolated
|
|
# env -- ruff, mypy, pylint, bandit and codespell each come from their
|
|
# own repo+rev, and the local hooks need nothing beyond bash and
|
|
# python3 -- so installing the full requirements.txt spent 9s a run on
|
|
# packages no pre-commit-stage hook imports. Verified by running all
|
|
# three configs green in a venv holding pre-commit and nothing else.
|
|
# The pin is read out of requirements.txt rather than repeated here, so
|
|
# it cannot drift from what the dependency-freshness gate governs.
|
|
- name: Install pre-commit
|
|
run: |
|
|
pip install "$(grep '^pre-commit==' gatelock/requirements.txt)"
|
|
|
|
# Keyed on THIS package's config. pre-commit/action@v3.0.1 caches on
|
|
# hashFiles('.pre-commit-config.yaml') -- the repo ROOT's -- so all three
|
|
# package jobs shared one key, raced to overwrite it with hook sets built
|
|
# from four different configs, and editing a per-package config did not
|
|
# invalidate it. The cache was therefore silently wrong rather than
|
|
# missing, and the hooks reinstalled from scratch on every run (38-49s).
|
|
- uses: actions/cache@v4
|
|
with:
|
|
path: ~/.cache/pre-commit
|
|
key: >-
|
|
pre-commit-gatelock-${{ env.pythonLocation }}-${{
|
|
hashFiles('gatelock/.pre-commit-config.yaml') }}
|
|
# Prefix fallback, or this fix would evaporate on the very
|
|
# event that motivated it: bumping a hook rev changes the
|
|
# exact key, and a total miss means reinstalling every hook
|
|
# again. pre-commit's store is keyed internally by hook
|
|
# repo+rev, so a superseded entry is ignored disk rather
|
|
# than a wrong hook, and cache still re-saves under the new
|
|
# exact key after a prefix-only hit.
|
|
restore-keys: pre-commit-gatelock-${{ env.pythonLocation }}-
|
|
- name: Run the hooks
|
|
run: >-
|
|
pre-commit run --config gatelock/.pre-commit-config.yaml
|
|
--all-files --show-diff-on-failure
|