Allow release tags to deploy the site (#53)

Every release-triggered **Publish site** run has failed since the
manifests were added —
0.9.3-dev.3238, 0.9.3-dev.3241, 0.9.3, 0.9.4-dev.3243, and 0.9.4 — each
in two to four
seconds:

```
Tag "v0.9.4" is not allowed to deploy to github-pages due to environment protection rules.
```

A release event runs on the tag, and the `github-pages` environment
allowed only `main`.

## Why it went unnoticed

Pushes to `main` kept deploying normally, so the workflow looked
healthy. What silently
stopped was the part that only a release triggers: regenerating
`stable.json` and
`dev.json`. The manifest served from `whiteboard.sqlbi.com` stayed on
0.9.2 while 0.9.3 and
0.9.4 shipped.

That is not cosmetic. The download page reads `stable.json` first and
only falls back to the
API on a 404, and the in-app update check reads the same file — so every
0.9.2 user was
being told they were current, two releases late.

## The fix

The environment now carries a tag rule for `v*` alongside the branch
rule for `main`,
applied to the repository settings. A manual deploy has already been
run, so the live
manifest reports 0.9.4.

This change records the requirement, because it is invisible from the
repository — the same
class of dependency as the Pages source setting it now sits beside, and
worth writing down
in both places a reader might look.

Author: marcosqlbi

.github/workflows/publish-site.yml

@@ -3,6 +3,14 @@
 # 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.
 #

docs/release-management.md

@@ -129,8 +129,19 @@ tied to the `sqlbi` publisher, then add it under the GitHub repo **Settings →
 variables → Actions**. Forks never receive it.
 
 **Publish site** (`.github/workflows/publish-site.yml`) deploys `site/` to GitHub Pages
-when that tree changes on `main`, and on **Run workflow**. It needs **Settings → Pages →
-Source: GitHub Actions**. `site/CNAME` carries the custom domain.
+when that tree changes on `main`, when a release is published, and on **Run workflow**.
+`site/CNAME` carries the custom domain.
+
+Two settings outside the repository have to be right, and each fails in its own quiet way:
+
+- **Settings → Pages → Source: GitHub Actions.** With the default "Deploy from a branch"
+  the workflow runs and deploys nothing.
+- **Settings → Environments → `github-pages` → Deployment branches and tags** must allow a
+  branch rule for `main` *and* a tag rule for `v*`. A release event runs on the tag, so
+  without the tag rule every release-triggered run is rejected within seconds while pushes
+  to `main` keep working — which means the manifests quietly stop tracking releases and the
+  download page keeps offering an old version. That is precisely what happened between
+  0.9.3 and 0.9.4.
 
 ### Azure Pipelines