From dea9badfed6c50a8d736baa5527a4ae648b748d0 Mon Sep 17 00:00:00 2001 From: Cameron Brooks Date: Sat, 5 Sep 2026 17:11:20 -0400 Subject: [PATCH] ci(docs): redeploy when the lock changes, and allow manual dispatch The site is built with `uv sync --group docs`, so what it ships is decided by uv.lock -- but uv.lock was not a trigger path. A dependency fix could land on main while the deployed site kept serving the previous build, with no way to force a rebuild: there was no workflow_dispatch either. That is not hypothetical. mkdocs-material 9.7.6 (GHSA-xvg9-69gf-fjrf, DOM XSS in search suggestions) was live on the published docs, and merging the 9.7.7 bump alone would have closed the alert while leaving the vulnerable build served. orlab's docs workflow already has the right shape: no path filter plus workflow_dispatch. --- .github/workflows/docs.yml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml index 75e95d0..0b7710b 100644 --- a/.github/workflows/docs.yml +++ b/.github/workflows/docs.yml @@ -10,6 +10,13 @@ on: - "CHANGELOG.md" - "CONTRIBUTING.md" - ".github/workflows/docs.yml" + # The site is built with `uv sync --group docs`, so what ships is decided + # by the lock, not just by the sources above. Without these two paths a + # dependency fix lands on main and the deployed site keeps serving the old + # build -- which is how mkdocs-material 9.7.6 stayed live on the published + # docs after GHSA-xvg9-69gf-fjrf was already patched in the lock. + - "uv.lock" + - "pyproject.toml" pull_request: branches: [main] paths: @@ -19,6 +26,11 @@ on: - "CHANGELOG.md" - "CONTRIBUTING.md" - ".github/workflows/docs.yml" + - "uv.lock" + - "pyproject.toml" + # Lets the site be rebuilt without inventing a commit -- there was previously + # no way to redeploy at all. + workflow_dispatch: permissions: contents: read