In the past few days, the opportunity to run only the documentation pipelines when there are changes to the documentation folder has come up more than once [1].
There have been suggestions on how to deal with this on Mastodon by @jeff and @sabderemane , which could be a starting point to improve the situation.
The advantages would certainly be the speeding up of the pipelines for changes to the documentation only, the reduction of energy required for each change to the documentation.
It also emerged in a thread of the Saturn team of the Dajngonaut Space project, how sometimes, when there are changes to the docs, the tests fail for reasons totally unrelated to the changes themselves.
Before opening an issue or proposing code, I wanted to share this idea here and receive feedback.
If someone wants to take charge of the matter because they think they already know how to solve the problem, they are welcome.
The advantages would certainly be the speeding up of the pipelines for
changes to the documentation only, the reduction of energy required
for each change to the documentation.
It also emerged in a thread of the Saturn team of the Dajngonaut Space
project, how sometimes, when there are changes to the docs, the tests
fail for reasons totally unrelated to the changes themselves.
So there are basically two issues here?
flaky (code) tests, that randomly fail regardless of the changes
separating the build process for the documentation from the rest to
have faster builds for documentation only changes
prevent doc only changes to fail because of flaky (code) tests?
The point here is only tu run the only doc-related pipeline when a doc changes occur, having the same tests flow, but only with conditions.
If you don’t run other pipeline (e.g. Python 3.12 Postgres) typically you skip also the flaky tests which you have still to solve to rub tests for other changes, but this is another issue.
Bazel is made for this problem, but I only have experience using it in a private environment where malicious cache poisoning and the like is not a concern. Bit of a Pandora’s box to propose Bazel for Django’s CI.
Though I have to say that when you have Bazel set up, pushing up a readme change and having a green check after 2 seconds instead of 40 minutes is wonderful.
(EDIT: GH actions do seem good enough here though, especially if commits to main branches still get tests run fully)
We seem to be using the git plugin for Jenkins: Git. This has Polling ignores commits in certain paths and I have updated the “Excluded regions” to docs/* in our job configurations - but this doesn’t seem to have the desired effect
In short, I am happy to make this happen but I don’t really know how to achieve it
Great. But you changed the Jenkins configuration, but that is not public?
I see a lot of small doc changes in PR list, some of them are quite ready to be merged. We can concentrate in one of the smallest one to be able to merge it ASAP and trigger Jenkins.
Correct, the configuration around the job triggers require a Jenkins account (with some access)
Some stuff related to Jenkins is public, like the ansible playbooks:https://github.com/django/jenkins-ansible but I think not relevant for the current task
I pushed to a docs pr. There’s a queue for running things. Build 28062 for pull-request-focal is a docs only change: pull-requests-focal [Jenkins]