Three defects, found by reviewing this branch against a running pytest rather
than by reading it.
Exit 5 is not a failure. pytest reserves it for NO_TESTS_COLLECTED, and
`|| fail "pytest failed"` collapsed it into a blocked push. The `|| fail`
predates this branch, but this branch is what makes it reachable: a repository
whose pyproject.toml only configures ruff or black, with pytest in its venv and
no test files, used to hit the "pytest is not installed" skip and now gets
gated. $VIRTUAL_ENV is the first candidate, so merely having a venv activated in
the pushing shell drags any requirements.txt repository into this path, and the
hook is installed globally. Reproduced with pytest 9.1.1. Exit 5 is now
non-blocking but loud -- a bad rootdir, testpaths or an unimportable conftest
also collects nothing, and swallowing that silently would reopen the hole this
resolver exists to close. Other non-zero codes now carry the code, because 1
(tests failed) and 4 (usage error) call for different responses.
The ECC_PYTEST_CMD probe ran the operator's command. Validating the override
with `--version` assumed it would answer like pytest. A wrapper that sets an
environment variable and execs pytest ignores the flag and runs the whole suite,
so the probe executed the tests, then rejected the command for not printing a
version, then blocked the push -- with the suite green. That is worse than the
silent gate the probe was added to close, so the override is taken as given
again: it is a deliberate setting, the hook cannot inspect it without running
it, and pointing it at something that is not pytest is the operator's call.
`is_pytest` still guards the PATH candidate, which this script composes itself,
where `pytest --version` is harmless. An empty override still fails closed.
The tests inherited the ambient environment. `runHermeticPythonPrePush` passed
process.env through, so an exported ECC_PYTEST_CMD or an activated virtualenv
resolved a pytest the fixture never created and the venv test failed for anyone
who runs the suite that way. Both variables are now neutralised in the base env.
Coverage: the gate had no test proving it blocks. Changing the run line to
`|| true` left all three previous tests green. Seven now cover a spaced venv
path, a red suite, exit 5, an override invoked exactly once with no probe, an
empty override, and the PATH candidate in both directions.
Two holes in the resolver this branch added, both found in review.
A virtualenv path may contain spaces. `resolve_pytest` returned one string and
the caller expanded it unquoted, so `/home/me/my env/bin/python -m pytest` split
into `/home/me/my` and `env/bin/python`. The probe that accepted the candidate
was correctly quoted, so the hook reported the venv as usable and then failed to
run anything in it -- rejecting the push for a reason with nothing to do with
the code being pushed. It now builds an argv array and runs `"${PYTEST_CMD[@]}"`.
The resolver's contract is that every candidate is confirmed to be pytest, and
two of them were not. `ECC_PYTEST_CMD` was returned unchecked, so
`ECC_PYTEST_CMD=true` made the hook run `true -q`, exit 0 and report a Python
project verified by nothing. The PATH branch used `command -v pytest`, which
proves only that a file of that name exists. Both now go through `is_pytest`,
which runs `--version` and requires the output to name pytest -- `--version`
alone is not evidence, since `true --version` also exits 0.
A bad `ECC_PYTEST_CMD` fails the push rather than falling through to the next
candidate. An operator who set it asked for that command, and silently running
a different one hides the misconfiguration -- which is the same silent-gate
failure this branch exists to remove, one level along.
Three regression tests cover the three paths: a venv whose directory name
contains a space, an override that is not pytest, and an override that is.
The Python block gates on `command -v pytest`, so it only runs when pytest is
on PATH. Installing a project's tools into a virtualenv is the norm rather
than the exception, so in practice the hook printed
[ECC pre-push] Python project detected but pytest is not installed. Skipping.
while standing in a directory with `.venv/bin/pytest` in it, and pushed.
The failure mode is worse than not having the hook. A skip line reads like a
pass: the push succeeds, the output looks healthy, and nothing indicates the
gate declined to gate. A repository can sit behind it for months believing
its tests run on every push. Found on a project with 893 tests, none of which
the hook had ever executed.
`resolve_pytest` now looks, in order, at `ECC_PYTEST_CMD`, `$VIRTUAL_ENV`,
`.venv`, `venv`, `env`, `uv run` when a `uv.lock` is present, `poetry run`
when a `poetry.lock` is, and finally PATH. Each candidate is confirmed by
importing pytest rather than by the path existing, so a half-built venv falls
through to the next one instead of failing the push.
Two deliberate choices:
The log line names the command it resolved -- `Running: .venv/bin/python -m
pytest -q` -- so which interpreter ran is visible in the push output rather
than inferred. When nothing resolves, the message says where it looked and
names `ECC_PYTEST_CMD`, instead of asserting pytest is not installed when it
may well be.
`uv run` passes `--no-sync` so the hook cannot mutate the developer's
environment on its way to running the tests.
Behaviour change worth flagging for the release note: on any Python project
with a working virtualenv this hook now actually runs the suite, and will
block a push whose tests fail. That is the intent, but it is new behaviour
for every such repository, and `ECC_SKIP_PREPUSH=1` remains the escape.
Verified on two real repositories: a uv/venv Python project (resolves
`.venv/bin/python -m pytest`, 893 tests, exits 0; exits 1 when the suite
fails) and a Node project (unchanged, still runs lint/typecheck/test/build).
The pre-push hook runs lint/typecheck/test/build checks on every push,
including `git push origin --delete <branch>`. Branch deletion does not
push any code, so verification checks are unnecessary and block the
delete operation.
Detect deletion pushes by reading stdin (local sha is all zeros for
deletes) and exit early.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Juan Garibay