From 2d618f29ad538a28dafbc0b7b15899c8655a27a3 Mon Sep 17 00:00:00 2001 From: tannevaled Date: Sun, 30 Aug 2026 17:47:04 +0200 Subject: [PATCH] Build the landing page on pull requests, publish only from main The Pages workflow triggered on `push` to main and `workflow_dispatch` only, so nothing ran on a pull request. Measured, not assumed: the two open Renovate pull requests here (#6 bumping actions/configure-pages, #7 bumping actions/deploy-pages) both report `total_count: 0` from `/repos/go-pdfkit/go-pdfkit.github.io/commits//check-runs`. A change to the very workflow that publishes the site was mergeable with nothing verifying it, and the first evidence of a mistake would have been a broken published site. Add a `pull_request` trigger so the build job proves the site still builds, and gate the deploy job on the event so a pull request never publishes. Permissions and concurrency follow from that: - the workflow now grants `contents: read` and `pages: read` only. `pages: write` and `id-token: write` move down to the deploy job, which is the only job that needs them; a pull request build therefore cannot publish even if a step in it misbehaves. `configure-pages` runs in the build job and reads the Pages settings to compute the base URL, which `pages: read` covers. - the concurrency group is scoped by ref. Deploys still serialise with one another under the main group, while each pull request gets a group of its own so it neither waits behind a deploy nor holds one up, and a new push to the same pull request supersedes the build still running for it. The action versions are deliberately left alone: pull requests #6 and #7 exist to bump them, and they are now the proof that the check actually appears. Co-Authored-By: Claude Opus 5 --- .github/workflows/deploy-pages.yml | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/.github/workflows/deploy-pages.yml b/.github/workflows/deploy-pages.yml index ea6897b..97ffd84 100644 --- a/.github/workflows/deploy-pages.yml +++ b/.github/workflows/deploy-pages.yml @@ -3,16 +3,28 @@ name: deploy-pages on: push: branches: [main] + # Build on every pull request too, so a change to the layout, the content, + # the Hugo version or one of the actions below has to prove the site still + # builds before it lands. Without this the workflow ran only on main, so a + # dependency bump arrived with no signal at all: its checks read "no checks", + # which is not the same thing as green and must not be merged as if it were. + pull_request: workflow_dispatch: +# The build needs nothing beyond the source and the Pages configuration it +# reads to compute the base URL. Publishing rights are granted to the deploy +# job alone, below, so a pull request build cannot replace what is served even +# if a step in it misbehaves. permissions: contents: read - pages: write - id-token: write + pages: read +# Deploys serialise with one another under the main group. A pull request gets +# a group of its own, so it neither waits behind a deploy nor holds one up, and +# a new push to the same pull request supersedes the build still running for it. concurrency: - group: pages - cancel-in-progress: false + group: pages-${{ github.ref }} + cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: build: @@ -40,8 +52,16 @@ jobs: path: public deploy: + # Only main publishes. A pull request stops after the build above: it has + # proved the site builds, which is the whole point of the gate, and it has + # no business replacing the published site. + if: github.event_name != 'pull_request' needs: build runs-on: ubuntu-latest + permissions: + contents: read + pages: write + id-token: write environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }}