Discussion: Possible CI improvements

Django Internals
1

Hi everyone :waving_hand:
I’m starting this thread to ask how we should discuss and improve CI-related topics, and to get early feedback before opening issues or PRs.

These ideas came up from a recent Discord discussion about CI, and I want to keep this high-level and exploratory.

1. Using pre-commit hooks in CI

Would it make sense to run pre-commit in CI instead of running individual linters directly?

Possible benefits:

  • Consistency between local development and CI

  • Easier to add or remove checks in one place

Open question:

  • Are there known downsides to relying on pre-commit in Django’s CI?

2. Linting performance (Black, isort, Ruff)

Black and isort currently take noticeable time in CI. Ruff seems mature now and could potentially replace some checks and reduce runtime significantly.

This is not only about saving CI minutes, but also:

  • Faster feedback for contributors

  • Less waiting for reviewers

Questions:

  • Has Ruff been evaluated recently for Django?

  • Are there known blockers for adopting it (partially or fully)?

3. CI dependency updates

I noticed that some CI dependencies and GitHub Actions are not updated regularly.

Questions:

  • Do we have a documented process for updating CI dependencies?

  • Is this done manually, or should we consider automation (Dependabot / Renovate)?

  • Hash pinning could also help here (some tools already enforce this).

4. CI structure and gating

One idea discussed was:

  • Run lint / pre-commit first

  • Only run the full test suite if linting passes

I understand there are trade-offs:

  • Sometimes linting can break due to external reasons

  • Tests may still be useful even if lint fails

So the question is:

  • Is gating tests behind linting something worth considering, or is it intentionally avoided?

Goal of this post

I’m not proposing a concrete change yet.
The goal is to:

  • Understand existing constraints

  • Learn what was tried before

  • Find which ideas are worth turning into issues or PRs

Thanks for your time, and happy to split this into separate topics if needed.

2

The beginning of the related discussion in Discord (and a thread) can be found at this link.

I believe all of the items in this topic are big enough to deserve their own discussions. I don’t expect a generalized “improvement” discussion to yield results, considering how rooted each problem/improvement is and the level of detail required to properly evaluate them.

That being said, the first 3 items were originally my proposals, and I still support them. I just think this is not the best way to discuss them.

3

None of these ideas are really new. See e.g. Alternative formatters for generated code, like `ruff format`? for using ruff as a formatter, and some later comments on linting and import sorting.

For the rest it’s hard to find clear conversations, but I’ve been involved in at least some of them and from what I (possibly incorrectly) remember:

Using pre-commit hooks in CI I think was discussed at some point but I’m not sure there was any resolution. At the moment things that run in pre-commit are already run as separate linters, which you can argue is nice because you immediately know which thing is failing. I believe we also use an extra action to show as github annotations where each failure is occurring, and I’m not sure if this would work with pre-commit or not.

Linting performance has been discussed (by me at least) in a few venues and at the time ruff was a bit too new to switch to. I think there’s a good case to be made to revisit this.

For CI dependencies, I don’t remember any discussion but I’m not sure exactly how much value I see. Most things are already not pinned and will use the latest. The exception here pre-commit hooks, maybe could do something about this but I don’t believe dependabot supports updating pre-commit hooks. Renovate could work but I think easier to not worry about an external system just to manage this and just run pre-commit auto-update in a GitHub Actions workflow and be done with it. But I’m not sure what the current workflow is, it could be they are already updated at specific times, e.g. before / after a release. Not sure on this.

CI gating has also been discussed before (somewhere…) but IIRC it was decided against because sometimes (e.g.) a linter can fail due to no problem in your branch but a problem elsewhere and you definitely don’t want to stop the tests from running in these cases.

4

Below are something I want to add:

  1. use uv
  2. also use tools to format and lint: js, css, html (many full stack Django projects only have good style in py. But code in html, css are very ugly and not maintainable)
  3. concurrent test