Skip to content

SQLBI Whiteboard 1.1.0 #53

SQLBI Whiteboard 1.1.0

SQLBI Whiteboard 1.1.0 #53

Workflow file for this run

# Publishes site/ to GitHub Pages.
#
# Requires Settings -> Pages -> Build and deployment -> Source: GitHub Actions. With the
# default "Deploy from a branch" this workflow runs and deploys nothing.
#
# It also requires a deployment policy on the github-pages environment that allows the
# release tags, under Settings -> Environments -> github-pages -> Deployment branches and
# tags: a branch rule for main, and a tag rule for v*. A release event runs on the tag
# rather than on a branch, so without the tag rule every release-triggered run is rejected
# in a couple of seconds with "Tag ... is not allowed to deploy to github-pages due to
# environment protection rules" - and the manifests silently stop tracking releases while
# ordinary pushes to main keep deploying fine.
#
# site/CNAME carries the custom domain, so it survives every deployment rather than
# depending on the setting alone.
#
# The deployment also carries stable.json and dev.json, generated here rather than
# committed. They are served from the same origin as the page, which is the only way the
# page can read them: github.com release-asset URLs send no Access-Control-Allow-Origin
# header, so a manifest published as a release asset is unreadable from a browser.
name: Publish site
on:
push:
branches: [main]
paths:
- 'site/**'
- 'scripts/build-release-manifests.ps1'
- 'scripts/verify-published-site.ps1'
- '.github/workflows/publish-site.yml'
# A release changes what the manifests say without changing anything in site/, so it has
# to redeploy the page as well. This is what keeps the download links current.
release:
types: [published]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
# One deployment at a time, and never cancel one midway: a half-applied deployment would
# leave the site in whatever state it reached.
concurrency:
group: pages
cancel-in-progress: false
jobs:
deploy:
name: Deploy to GitHub Pages
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- uses: actions/checkout@v5
# Generated into the checkout, so the manifests ship with the page in one
# deployment. Both files are gitignored: this is the only thing that writes them.
# ExpectTag is empty for every trigger except a release, and that is the point: a
# release event fires seconds before the releases API lists the release, so without
# it this step reads the previous version and writes a stale manifest while
# reporting success. That happened to 0.9.5.
- name: Generate the release manifests
shell: pwsh
run: ./scripts/build-release-manifests.ps1 -Repository "$env:GITHUB_REPOSITORY" -OutputFolder site -Token "$env:GH_TOKEN" -ExpectTag "$env:EXPECT_TAG"
env:
GH_TOKEN: ${{ github.token }}
EXPECT_TAG: ${{ github.event.release.tag_name }}
- uses: actions/configure-pages@v5
- uses: actions/upload-pages-artifact@v3
with:
path: site
- id: deployment
uses: actions/deploy-pages@v4
# A Pages deployment can report success, be recorded as the active deployment, and
# still leave the site serving the previous one. Every step above went green for
# 1.0.0 while the download page offered 0.9.5, and nothing said so; re-running this
# workflow published the same files and fixed it. Reading the site back is the only
# place that failure is visible, so it fails the run that caused it rather than
# waiting to be noticed.
- name: Verify the site is serving this deployment
shell: pwsh
run: ./scripts/verify-published-site.ps1 -Folder site