pinecrew / pined-django / 33511604326

95%

main: 95%

push

github

ci: one job per extra, at both ends of its own ranges

`uv sync --extra settings` does not install what a project asking for only
that extra would get. uv resolves the project as a whole however few extras it
then installs, so `pydantic>=2.12` from `pydantic-field` decides the version
`settings` gets too — and the `>=2.10` that extra declares was never once the
version under test. `uv pip install -e ".[settings]" --group dev` resolves that
extra and nothing else; pydantic 2.10.0 turns up, as declared.

Four jobs, `{settings, pydantic-field}` × `{lowest-direct, highest}`. The top
end is not the matrix repeated: one extra is installed, so a module reaching
across to something only the other one brings fails there rather than in the
install of whoever wanted just the one.

`tests/settings` needs a settings module of its own for this — `tests.conf`
installs the test app, whose models declare a `PydanticField`, and importing
one pulls in `json_schema_to_pydantic` from the other extra. `tests.conf_settings`
leaves the app out, and the admin tests, which assert the ordering against it,
skip themselves when it is not installed. Ninety of the ninety-six run.

`test (lowest direct)` stays as it is: everything installed, whole suite, the
bottom of every range at once.

229 of 250 branches covered (91.6%)

Branch coverage included in aggregate %.

1297 of 1360 relevant lines covered (95.37%)

0.95 hits per line