The dependency canary tests the locked tree, not the fresh resolution

[wtgee]

Found while porting this repository's workflows to panoptes-pipeline (panoptes/panoptes-pipeline#226).

canary.yml resolves a fresh dependency tree and then runs the suite:

- name: Resolve dependencies afresh
  run: uv sync --upgrade --group test --python ${{ matrix.python-version }}

- name: Run tests
  run: uv run pytest -q

uv run syncs against the lockfile before running unless told not to. So the second step undoes the first: the fresh resolution is replaced by the pinned tree, and the suite runs against exactly the versions the pull-request jobs already test.

The result is a canary that cannot fail for the reason it exists. It has been green since it was added, which is what you would expect either way -- that is the part that makes this worth fixing rather than noticing later.

Fix

- name: Run tests
  run: uv run --no-sync pytest -q

While in there

Two smaller things in the same file, both about the sync installing more than intended:

• uv sync --upgrade --group test also installs the default dev group, which includes docs. The canary then resolves and installs zensical and mkdocstrings in order to run pytest. --no-default-groups --group test is what was meant.
• The same --group / default-group interaction applies to tests.yml and docs.yml, where it costs install time rather than correctness.

See project standards 6.5 in panoptes-pipeline for the written-up version.

Done when

The canary tests the tree it resolved. Worth confirming by reading one run's "Show the resolved tree" output against uv.lock -- if they match, it is still not doing anything.

---

_{Filed by Claude Opus 5 · effort: high · 🤖 Claude Code}