Restore the dry privacy copy, and keep the FAQ in step (#57) #30
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
| # 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' | |
| - '.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 |