ci(docs): stop installing an unused TeX stack; bound the docs job - #358
Merged
Merged
Conversation
The docs build on main ran 150 minutes instead of its usual 6. Nothing in the build got slower: the commit it ran on (DOI-USGS#356) touched only CI config, and timing the two runs against each other shows notebook execution took 3.7 min in both. The whole 144 min difference was `apt` fetching the same 127 packages -- 314 MB at an effective 37 KB/s off a slow Azure mirror. Most of that download is a TeX stack an HTML build never reaches. No math extension is configured and nothing renders math to images, so latexmk, texlive-*, and dvipng -- ~266 MB, and 5 of the 6 slowest single-package waits in the bad run -- were downloaded and never executed. Dropping them removes the tail risk rather than reducing it: with pandoc alone (which nbsphinx does shell out to, and without which the build fails) there is no longer a large download to be slow. Verified by building with the TeX binaries off PATH: it succeeds, and all 44 non-notebook HTML pages are byte-identical to a build with them present. A bound belongs here regardless, since the next slow mirror will find whatever is left. `timeout-minutes: 30` is far under the 6 h default and well over a healthy build. It matters more than it looks: runs are serialized on the ref, so an unbounded run doesn't just lose its own docs, it holds the queue for every commit behind it -- which is why this surfaced as "docs are stuck on main" rather than as one slow run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The docs build on
mainran 150 minutes instead of its usual ~6. It was not a code regression and not the notebooks.The commit it ran on (#356) touched only CI config and
pyproject.toml—git diff f7c248b7 deba1331 -- docs/ demos/ dataretrieval/is empty, so the build inputs were byte-identical to the run before it, which took 6m28s.Timing the two runs against each other localizes it precisely:
aptdownload (127 pkgs)Notebook execution was identical. The entire difference was
aptfetching the same 314 MB at an effective 37 KB/s off a slowazure.archive.ubuntu.commirror. Single packages stalled for over 20 minutes each (mupdf-tools23.6 min,openjdk-21-jre-headless22.2 min).What this changes
1. Drop the TeX stack (~266 MB of the 314 MB). An HTML build never reaches it — no math extension is configured in
docs/source/conf.py(neithermathjaxnorimgmath), and nothing renders math to images.latexmk,texlive-*, anddvipngwere downloaded and never executed, yet accounted for 5 of the 6 slowest single-package waits. This removes the tail risk rather than trimming it: withpandocalone there is no longer a large download to be slow.pandocis kept —nbsphinxshells out to it for notebook markdown cells, and the build fails withPandocMissingwithout it (verified).2. Add
timeout-minutes: 30. The next slow mirror will find whatever is left, and the default is 6 hours. This matters more than it appears: runs are serialized on the ref (concurrency,cancel-in-progress: false), so an unbounded run doesn't just lose its own docs — it holds the queue for every commit behind it. That is why this surfaced as "docs are stuck on main" rather than as one slow run. A cell-levelnbsphinx_timeoutwas considered and deliberately left out, since notebook execution was never the problem here.Test plan
sphinx-build -b htmlwith TeX binaries offPATH→ build succeededexamples/pages differ only because notebooks re-execute against live data)math*.pngin either build — confirms nothing was rendering math via LaTeXpandocis genuinely required (removing it fails withPandocMissing)texlive/latexmk/dvipng🤖 Generated with Claude Code