Adds data-domains to the Umami script tag so the tracker only fires on schoolcompare.co.uk — staging traffic and E2E runs never reach the analytics. Also serves as the first end-to-end run of the new deploy pipeline.
Adds data-domains to the Umami script tag so the tracker only fires on schoolcompare.co.uk — staging traffic and E2E runs never reach the analytics. Also serves as the first end-to-end run of the new deploy pipeline.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01PqGhF93UrpDNvXBLMjJENL
The same frontend image runs on staging and prod (build once, promote), so a
build-time env var can't tell them apart. Umami's data-domains attribute
scopes the tracker client-side: events only fire when location.hostname is a
production domain, so staging traffic and the E2E journeys never pollute the
dashboards.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PqGhF93UrpDNvXBLMjJENL
This PR narrows CI/deploy secret usage (moving PR-review comment posting off the broadly-scoped REGISTRY_TOKEN) and adds a data-domains restriction to the Umami analytics snippet so staging traffic doesn't pollute production analytics. The analytics change is correct and low-risk, but the CI token change appears to reference a secret that Gitea Actions does not actually auto-provide.
🔴 Severe (blocks merge)
.gitea/workflows/pr-checks.yml: The workflow now reads secrets.GITEA_TOKEN and the added comment claims it's 'Auto-provided per-run token from Gitea Actions (repo-scoped)'. Gitea Actions only auto-injects a token under the name secrets.GITHUB_TOKEN (kept for compatibility with GitHub-style actions) — there is no built-in GITEA_TOKEN. Unless a repo/org secret literally named GITEA_TOKEN has been manually created (which contradicts 'no setup needed' in docs/DEPLOY.md), this env var resolves empty, ai_review.py's post_comment() gets a 401 from the Gitea API, the exception is unhandled, and the whole 'Review PR diff with Claude Code' job fails on every PR — breaking the merge-gating CI check repo-wide, including for this PR itself and any future production hotfixes.
🟡 Minor
docs/DEPLOY.md: Documentation repeats the same unverified claim that secrets.GITEA_TOKEN is automatically provided by Gitea Actions with 'no setup needed'; if that's inaccurate (see pr-checks.yml finding), this will mislead whoever debugs the resulting CI failures into thinking no secret needs to be created.
## 🤖 AI Code Review (Claude Code)
This PR narrows CI/deploy secret usage (moving PR-review comment posting off the broadly-scoped REGISTRY_TOKEN) and adds a data-domains restriction to the Umami analytics snippet so staging traffic doesn't pollute production analytics. The analytics change is correct and low-risk, but the CI token change appears to reference a secret that Gitea Actions does not actually auto-provide.
### 🔴 Severe (blocks merge)
- **.gitea/workflows/pr-checks.yml**: The workflow now reads `secrets.GITEA_TOKEN` and the added comment claims it's 'Auto-provided per-run token from Gitea Actions (repo-scoped)'. Gitea Actions only auto-injects a token under the name `secrets.GITHUB_TOKEN` (kept for compatibility with GitHub-style actions) — there is no built-in `GITEA_TOKEN`. Unless a repo/org secret literally named GITEA_TOKEN has been manually created (which contradicts 'no setup needed' in docs/DEPLOY.md), this env var resolves empty, `ai_review.py`'s `post_comment()` gets a 401 from the Gitea API, the exception is unhandled, and the whole 'Review PR diff with Claude Code' job fails on every PR — breaking the merge-gating CI check repo-wide, including for this PR itself and any future production hotfixes.
### 🟡 Minor
- **docs/DEPLOY.md**: Documentation repeats the same unverified claim that `secrets.GITEA_TOKEN` is automatically provided by Gitea Actions with 'no setup needed'; if that's inaccurate (see pr-checks.yml finding), this will mislead whoever debugs the resulting CI failures into thinking no secret needs to be created.
This PR swaps the AI-review job's PR-comment token from the long-lived REGISTRY_TOKEN to Gitea Actions' auto-provisioned per-run GITHUB_TOKEN, updates DEPLOY.md to match, and adds a data-domains attribute to the Umami analytics script so staging traffic isn't counted in production analytics. All three changes are small, internally consistent, and the docs accurately reflect the code/workflow changes.
✅ No issues found.
## 🤖 AI Code Review (Claude Code)
This PR swaps the AI-review job's PR-comment token from the long-lived REGISTRY_TOKEN to Gitea Actions' auto-provisioned per-run GITHUB_TOKEN, updates DEPLOY.md to match, and adds a data-domains attribute to the Umami analytics script so staging traffic isn't counted in production analytics. All three changes are small, internally consistent, and the docs accurately reflect the code/workflow changes.
✅ No issues found.
tudor
merged commit 515494dbf0 into main2026-07-03 13:17:53 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adds data-domains to the Umami script tag so the tracker only fires on schoolcompare.co.uk — staging traffic and E2E runs never reach the analytics. Also serves as the first end-to-end run of the new deploy pipeline.
🤖 Generated with Claude Code
https://claude.ai/code/session_01PqGhF93UrpDNvXBLMjJENL
🤖 AI Code Review (Claude Code)
This PR narrows CI/deploy secret usage (moving PR-review comment posting off the broadly-scoped REGISTRY_TOKEN) and adds a data-domains restriction to the Umami analytics snippet so staging traffic doesn't pollute production analytics. The analytics change is correct and low-risk, but the CI token change appears to reference a secret that Gitea Actions does not actually auto-provide.
🔴 Severe (blocks merge)
secrets.GITEA_TOKENand the added comment claims it's 'Auto-provided per-run token from Gitea Actions (repo-scoped)'. Gitea Actions only auto-injects a token under the namesecrets.GITHUB_TOKEN(kept for compatibility with GitHub-style actions) — there is no built-inGITEA_TOKEN. Unless a repo/org secret literally named GITEA_TOKEN has been manually created (which contradicts 'no setup needed' in docs/DEPLOY.md), this env var resolves empty,ai_review.py'spost_comment()gets a 401 from the Gitea API, the exception is unhandled, and the whole 'Review PR diff with Claude Code' job fails on every PR — breaking the merge-gating CI check repo-wide, including for this PR itself and any future production hotfixes.🟡 Minor
secrets.GITEA_TOKENis automatically provided by Gitea Actions with 'no setup needed'; if that's inaccurate (see pr-checks.yml finding), this will mislead whoever debugs the resulting CI failures into thinking no secret needs to be created.🤖 AI Code Review (Claude Code)
This PR swaps the AI-review job's PR-comment token from the long-lived REGISTRY_TOKEN to Gitea Actions' auto-provisioned per-run GITHUB_TOKEN, updates DEPLOY.md to match, and adds a data-domains attribute to the Umami analytics script so staging traffic isn't counted in production analytics. All three changes are small, internally consistent, and the docs accurately reflect the code/workflow changes.
✅ No issues found.