gh-145000: Run check-html-ids.py in CI

[StanFromIreland]

This doesn’t introduce any slowdown in the CI as the doctest job is slower. To avoid building the docs twice, I use the build from the build-doc step to run the script and upload the results.

🟢 Pass example
🔴 Fail example (When merged, it will properly fail, currently the script doesn’t sys.exit(1))

• Issue: Check removed HTML IDs #145000

---

📚 Documentation preview 📚: https://cpython-previews--145632.org.readthedocs.build/

[StanFromIreland]

Annoyingly, no exclude file exists on main yet, and trying to add one here won't work, since the PR base won't have it. So, I am forced to leave a TODO.

And we have the same issue with adding sys.exit(1) to fail the job, it's not on main yet.

[webknjaz]

I don't like that reusable-*.yml modules are getting more and more jobs. I was hoping to keep them with one job each with any info exchange through inputs/outputs...

[StanFromIreland]

I don't like that reusable-*.yml modules are getting more and more jobs. I was hoping to keep them with one job each with any info exchange through inputs/outputs...

In this instance, I think it is better to group them, creating a new module will just introduce more issues with passing inputs IMO.

[hugovk]

So we're building docs in the PR, then checking out the base branch, building the docs again, and comparing?

It only takes a couple of minutes for that base branch build, but it feels like we could avoid this extra CI work somehow?

Of course, we don't build docs for every PR, so that reduces it. And we also don't build docs for regular pushes to main, which complicates things.

[encukou]

So we're building docs in the PR, then checking out the base branch, building the docs again, and comparing?

Yeah, that's wasteful.
I was thinking about building and publishing these on docs.python.org. Would that make sense to you?

[StanFromIreland]

I was thinking about building and publishing these on docs.python.org. Would that make sense to you?

Then we'd have to host it for every commit, or accept that much more frequent branch updates are necessary (which is also wasteful). For example, commits:

main
- A
- B (Adds an ID)

PR:
- A (base)
# Behind, missing B
- C (Unrelated changes by the PR)

When the CI runs on C, it will pull the base IDs. But, the IDs added by B will be missing at C, so the CI will falsely report it as removed.

[StanFromIreland]

For the record, we discussed this during Petr's docs meeting yesterday.

• We concluded that storing and pulling from docs.python.org won't work, for the reason outline in gh-145000: Run check-html-ids.py in CI #145632 (comment).
• We then considered merging in the main branch, then building and pulling the base from from docs.python.org. However, we found this would be quite complicated, and would also cause issues in some cases, and as such is not worth it.
• We decided we don't need to run the check on push. (Sending a commit to address this)

[StanFromIreland]

I don't like that reusable-*.yml modules are getting more and more jobs. I was hoping to keep them with one job each with any info exchange through inputs/outputs...

After some more thought, it does not actually complicate anything, and as such, I have decided to do this.

[vstinner]

This change introduced errors in the GHA Lint CI: https://github.com/python/cpython/actions/runs/23850561184/job/69529219964?pr=147962 (from PR gh-147962)

Example:

  error[: unpinned action reference
    --> .github/workflows/reusable-check-html-ids.yml:19:15
     |
  19 |         uses: actions/checkout@v6
     |               ^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
     |
     = note: audit confidence → High
     = help: audit documentation → https://docs.zizmor.sh/audits/#unpinned-uses

Since this PR was created (1 month ago), zizmor was made more strict (see commit a504c0a of issue gh-146488).