feat(ci): fail the build on a sidebar link to a deleted /api page - #12398
Conversation
The repaired link check catches this bug class, but only on a pull request, and a pull request is not how it arrives. `/api/*` routes are generated from the OpenAPI spec's tags, and that spec lands by bot sync pushed straight to main — no pull request, so no CI. A tag rename would deploy the 404 and stay broken until some unrelated pull request tripped over it days later, failing on a link its author never touched. Add the gate where a schema sync actually passes: the build. This mirrors validate-data-type-anchors, which exists for the same reason against the same sync, and pairs it with a unit test so docs-side edits still get the faster signal in pull request CI. The check is fed the same preprocessed schema and the same `groupByTag` / `slugifyTag` that `src/pages/api/[tag].astro` uses to emit the routes, so it cannot disagree with what the build produces, and it reads `src/content/docs/api/` through the same recursive, partial-excluding glob the docs collection uses, so adding a hand-written page needs no change here. A nav path is resolved without its anchor or query: navItems already ships anchored entries elsewhere, and the `/api` pages are the ones with a heading per endpoint, so reading an anchor as part of the slug would fail the deploy on a link that resolves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Change-Id: Ic67fc8c90348b1693fa3c5254157de8a000085f4
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge Protections🔴 3 of 7 protections blocking · waiting on 👀 reviews and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
sileht
marked this pull request as ready for review
August 15, 2026 20:58
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The repaired link check catches this bug class, but only on a pull request,
and a pull request is not how it arrives.
/api/*routes are generated fromthe OpenAPI spec's tags, and that spec lands by bot sync pushed straight to
main — no pull request, so no CI. A tag rename would deploy the 404 and stay
broken until some unrelated pull request tripped over it days later, failing
on a link its author never touched.
Add the gate where a schema sync actually passes: the build. This mirrors
validate-data-type-anchors, which exists for the same reason against the same
sync, and pairs it with a unit test so docs-side edits still get the faster
signal in pull request CI.
The check is fed the same preprocessed schema and the same
groupByTag/slugifyTagthatsrc/pages/api/[tag].astrouses to emit the routes, so itcannot disagree with what the build produces, and it reads
src/content/docs/api/through the same recursive, partial-excluding glob thedocs collection uses, so adding a hand-written page needs no change here.
A nav path is resolved without its anchor or query: navItems already ships
anchored entries elsewhere, and the
/apipages are the ones with a headingper endpoint, so reading an anchor as part of the slug would fail the deploy
on a link that resolves.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Depends-On: #12397