ci(docs): fail the docs job when its install fails

[thodson-usgs]

What

Two one-line changes to .github/workflows/sphinx-docs.yml.

1. shell: bash -l {0} → bash -leo pipefail {0}. Setting shell: replaces the default bash -e {0}, and -l alone carries no -e, so a failed install did not stop the step. In the v1.3.0 release build, pip install .[doc,nldi] failed and the step ran on to apt and make html, finally dying at sphinx-build: not found (exit 127) — naming the wrong culprit.

The latent hazard is worse than the confusing message: with a stale sphinx present on the runner, that step exits 0, so a docs set built from a failed install would deploy to gh-pages as if nothing were wrong.

Demonstrated locally:

$ bash -l         script   # pip install fails → continues → exit=0
$ bash -leo pipefail script  # pip install fails → aborts   → exit=1

2. Push trigger → branches: ["**"], so tag pushes no longer start docs builds. The deploy step is already gated on refs/heads/main, so a tag build can never publish anything; meanwhile GitHub pushes an untagged-<sha> placeholder tag for every draft release, and each one starts a docs build that fails in setuptools_scm, which cannot parse that ref as a version.

Naming branches alone is what excludes tags, per the workflow-syntax reference: "if you define only tags/tags-ignore or only branches/branches-ignore, the workflow won't run for events affecting the undefined Git ref." Note that the reflexive tags-ignore: ["**"] spelling would have done the opposite — excluding branch pushes and stopping docs builds entirely.

Testing

• YAML parses; triggers resolve to {push: {branches: ['**']}, pull_request: None}.
• actionlint: no new findings versus main (the 3 pre-existing warnings about undefined inputs on the pages-deploy action are unchanged).
• Shell semantics verified both ways, as above; -e with a login shell is the combination setup-miniconda recommends for GitHub runners.
• pre-commit check-yaml passed.

Note

This does not turn the current red CI green. Those failures come from the v1.3.0 release having been published with untagged-13b6562c80438aa8ea78 as its tag instead of v1.3.0; that tag sits on main's tip, so setuptools_scm cannot infer a version and any build from source fails. That needs to be fixed separately, by deleting the release and the stray tag and re-releasing on a real v1.3.0 tag.

🤖 Generated with Claude Code