Read the Docs supports pull request builds, where pull requests trigger preview builds that are published to a different domain and marked with a warning banner to prevent confusion, and where the build status is reported as one of the CI checks for the PR.

I recommend enabling this for GitPython. Unlike some CI checks that are configured in GitHub Actions workflow files, my understanding is that Read the Docs pull request builds, including their status reporting as CI checks, do not use GitHub Actions. Instead, pull request builds are triggered via webhook (as are other Read the Docs builds), and the check status is reported to GitHub by authenticating with OAuth and posting it with (I think) the GitHub API.

For this reason, I don't believe I can propose the necessary changes by pull request. Instead, if you choose to enable pull request builds, you can do so by following these official instructions.

This should make it easier to verify the correctness of documentation changes in pull requests, as well as make it easier for contributors (including me) to become aware of, investigate, and attempt to improve problems in Read the Docs builds.

My immediate motivation for recommending this change is the hope that it would enable me to submit and test a fix for #1840. However, even if it turns out that the effect of changes to .readthedocs.yaml are not fully previewed in pull request builds--I think they are but I am not sure--it seems to me that this would be a worthwhile addition to the project's CI checks.

Currently the pythonpackage.yml workflow does test if a local documentation build is able to succeed, but this does not test if a remote (Read the Docs) build succeeds, and more importantly it does not produce a hosted preview of the built documentation that can be easily inspected.