CI/CD Modernisation: Fully uv-native Workflows

[tschm]

CI/CD Modernisation: Fully uv-native Workflows

This PR rewrites the GitHub Actions CI and release pipelines to be fully managed by uv, removing all usage of
actions/setup-python and system Python.

Main changes

.python-version — adds a pinned 3.12 file so the project has a single canonical Python version for local development
and the coverage job.

main.yml — complete rewrite:

• Python is now installed and pinned per job via uv python install / pin, replacing actions/setup-python
• pre-commit is run via uvx (no separate install step)
• Changed-file detection now correctly falls back to the full repo on pushes to main (not just PRs)
• Adds a uv pip check dependency graph validation step to every test job
• Adds a uv venv step before each uv pip install (fixing the "no virtual environment found" error)
• Adds fail-fast: false consistently across all matrix jobs
• Drops the now-unused setup-project composite action

release.yml — complete rewrite:

• Runs check_tag, build, test, and publish jobs inside the official ghcr.io/astral-sh/uv container, eliminating all
  system-Python dependencies
• Tests the built wheel (not the source tree), catching packaging mistakes before upload
• Uses OIDC trusted publishing — no stored API tokens
• Narrows the release test matrix to stable versions (3.10–3.13), leaving 3.14 for the main CI matrix

.github/actions/setup-project/ — deleted; fully superseded by the inline uv steps.

[fkiraly]

update: @tschm completely changed the content and description of the PR. The below was a reaction to a simple change that pinned the python version.

Not sure if this is needed because this is a package and we do not want to pin versions but support ranges? Can you please explain why this is beneficial in a package, as opposed to a production project?

[fkiraly]

@tschm, thanks - though I am wondering whether you used AI, since there are incorrect statements?

• "Narrows the release test matrix to stable versions (3.10–3.13), leaving 3.14 for the main CI matrix" -> python 3.14 is stable, it was released about half a year ago.
• "Uses OIDC trusted publishing — no stored API tokens" -> the CI already used trusted publishers.
• "Tests the built wheel (not the source tree), catching packaging mistakes before upload" -> I also thought the CI was already doing that.

Can you kindly re-check whether the PR contains only intended changes?

[fkiraly]

Also, have you seen this? #702
Your PR seems to be largely redundant given #702.

[tschm]

The current workflows and also #702 are unfortunately still using the old action and are somewhat interesting...

[tschm]

❯ assess the quality on a scale of 1 to 10

⏺ PR #702 — 5/10

The intent is good but the execution has several concrete problems:

• Quoting bug in release.yml: pip install "$WHEELNAME[all_extras] --group dev" — the --group dev is inside the string
  literal, making it invalid pip syntax. This would fail at runtime.
• Incomplete goal: actions/setup-python@v6 is still present in the release test_wheels job, contradicting the stated
  aim of removing it.
• Redundant checkout: code-quality calls actions/checkout@v6 twice — once at the top and again in a step named
  "Checkout code".
• Coverage cost: still runs a full 3-OS × 5-Python matrix (15 jobs) for what is just a reporting step.
• UV_SYSTEM_PYTHON: 1 lingers in the build job — a sign of incomplete migration.
• Action versions: uses checkout@v6, upload-artifact@v7, download-artifact@v7 — worth verifying these exist and are
  intentional, not typos of @v4.

On the plus side: the detect-notebooks-change job is a genuinely good idea that saves CI time, job renaming is cleaner,
and fail-fast: false is applied consistently.

---

PR #719 — 7.5/10

Substantially better. It achieves what it sets out to do cleanly and consistently. Specific strengths:

• Zero setup-python anywhere — goal fully met
• uv pip check in every test job is a nice reliability addition
• Single-interpreter coverage job is a sensible cost reduction
• OIDC publishing is explicitly configured
• Tests the built wheel, not the source tree
• Drops the composite action cleanly

Deductions:

• Notebooks always run — no change detection means 5 notebook jobs fire on every trivial PR, which can be slow and
  expensive.
• Release matrix is Ubuntu-only — reduces confidence that the wheel installs correctly on macOS/Windows before
  publishing.
• Codecov is if: false — dead code left in; should either be wired up or removed.
• Confusing variable name: PY_VERSION is used for the package version (read from pyproject.toml), not the Python
  interpreter version — misleading in context.
• The pinned container image (uv:0.9.30-bookworm) will require manual bumps to stay current.

---

Bottom line: #719 is the stronger PR by a clear margin. #702 has an outright runtime bug in the release pipeline and
doesn't fully deliver on its stated goal.

[fkiraly]

@tschm, I would like to warn you for your behaviour as it is neither kind nor welcoming. Without me saying anything about intent at this point in time.

I will describe how it looks from the outside: tingiskhan in #702 opens a very decent PR to clean up the CI jobs, and homogenize with rest of GC.OS stack which imo is useful to reduce maintenance burden.

You, on the other hand, have not interacted with the repo for months (which has been on hiatus). But just few days after the repository becomes active again, you open a PR that you now say is a better version of #702. You also spend some time in mock-grading the two pull requests, without interacting much directly with #702.

Most people will read this as patronizing, and also quite mean, especially to a new contributor to this repository.

Let me also ask you this: why do you feel it necessary to write "improved" versions of pull requests and explicitly rank/compare them, instead of working on the numerous other issues or ways this project could be helped - or opening this kind of pull request in the first place without anyone else working on it?

It does feel like an attempt to establish a "pecking order of seniority", whether it is intentional or not.

Please don't do this.

Interactions should be collegial, helpful, welcoming. Not "look, I can do this better than you, therefore I am ahead of you in the imaginary pecking order" (irrespective of whether the premise is true or not) or "I was here first, please leave" .

But try to be more something like: "we should, as a community of peers, enable everyone to reach their potential to their fullest, irrespective of who is more or less senior/experienced in the team".

Ok?

[tschm]

Sorry, I don't have time to get into what's wrong with the code or my approach with it. I gave you an alternative implementation (for the fun of it and to demonstrate what .python-version is for) and I hope you guys are learning from it. Study what's going on. Don't rely just on the comments -- as you have pointed out, they can be inaccurate. Work on your pull request in #702 and embrace uv/uvx. You can also ignore the code given in this pull request. It's your project after all.