Skip to content

fix(watch): stale 8.28 fixture entry; run weekly and de-duplicate issues - #180

Merged
jeffredodd merged 1 commit into
mainfrom
claude/prod-watch
Oct 17, 2026
Merged

jeffredodd merged 1 commit into
mainfrom
claude/prod-watch

Conversation

@jeffredodd

Copy link
Copy Markdown
Member

Fixes #179

Root cause: the check was wrong, not production

Every production-watch issue since 2026-10-03 (#118 through #179) shows the same single failure:

FIXTURE FAIL  /docs/8.28/setup/quick-start: expected page, got redirect → /docs/setup/quick-start
docs-parity: fixture 43/44 passed.

The sitemap diff passed every time. The 9.10 snapshot (#117, merged 2026-10-03) pushed 8.28 past DEPLOY_VERSION_CAP = 12 in docusaurus.config.ts. That means 8.28 is no longer built, and its URLs are served as redirect stubs to the current docs, which is the intended behavior. The snapshot updated tests/baseline.json (it already maps /docs/8.28/setup/quick-start → /docs/setup/quick-start). Nobody updated the hand-picked tests/routes.fixture.json, so it still expected a page. Production (build-info.json: built 2026-10-05, siteSha 1704edb) is healthy.

Changes

  • tests/routes.fixture.json: /docs/8.28/setup/quick-start now expects a redirect to /docs/setup/quick-start. Live check against https://fiestaboard.app: docs-parity: fixture 44/44 passed.
  • tests/routes-fixture-versions.test.mjs (new, runs in npm test): checks each version-pinned fixture entry against versions.json and DEPLOY_VERSION_CAP. A version past the cap must be a redirect to /docs/<same path>. A built version must not redirect out of its own prefix. This test fails on the old fixture and passes on the new one. Heads-up: the open snapshot PRs (docs: snapshot version 9.11 #120, docs: snapshot version 9.12 #121, docs: snapshot version 9.13 #126, docs: snapshot version 9.14 #132) will each push another version off the cap. Once 8.29/8.30 fall off, this test will fail on those PRs until the /docs/8.30/... fixture entries are updated. That is deliberate: the snapshot PR's CI catches it instead of the production watch.
  • .github/workflows/watch.yml:
    • The cron goes from every 6h to weekly (41 14 * * 1, Monday 14:41 UTC). This is the downgrade that was due after 2026-08-29.
    • De-duplication: on failure, if an issue labeled production-watch is already open, the run comments on it (the oldest open one). Otherwise it files a new issue.

Verification

  • node --test tests/routes-fixture-versions.test.mjs tests/docs-parity.live.test.mjs: 13 pass, 0 fail
  • actionlint .github/workflows/watch.yml: clean
  • prettier --check on the changed files: clean

After this PR opened, the older duplicate watch issues were closed with a pointer to #179.

🤖 Generated with Claude Code

…ate issues

Production was never regressed. The 9.10 snapshot (#117, 2026-10-03) pushed
8.28 past DEPLOY_VERSION_CAP (12), so /docs/8.28/setup/quick-start became a
redirect stub to /docs/setup/quick-start, as designed. tests/baseline.json
was updated by that snapshot, but the hand-picked tests/routes.fixture.json
still expected a page, so every watch run failed and filed a new issue.

- routes.fixture.json: expect the 8.28 quick-start redirect.
- New tests/routes-fixture-versions.test.mjs checks fixture entries against
  versions.json + DEPLOY_VERSION_CAP, so the next snapshot PR that pushes a
  pinned version off the cap fails its own CI, not the production watch.
- watch.yml: cron every 6h -> weekly (the post-cutover downgrade that was
  due after 2026-08-29), and comment on an open production-watch issue
  instead of filing a duplicate.

Fixes #179

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Production watch: regression detected 2026-10-17

1 participant