Repository navigation
Conversation
akira28
approved these changes
Sep 22, 2026
Contributor
There was a problem hiding this comment.
Approved: no actionable issues found.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Mpdreamz
force-pushed
the
fix/nav-svg-sprite
branch
from
September 22, 2026 16:30
a957a09 to
be681f9
Compare
Mpdreamz
force-pushed
the
fix/nav-svg-sprite
branch
from
September 22, 2026 16:31
be681f9 to
f722413
Compare
Contributor
Docs preview (local build)Handbook preview: https://docs-v3-preview.elastic.dev/elastic/docs-builder/pull/4207/ |
Mpdreamz
force-pushed
the
fix/nav-svg-sprite
branch
2 times, most recently
from
September 24, 2026 14:06
386aa49 to
d3863b3
Compare
Mpdreamz
force-pushed
the
fix/nav-svg-sprite
branch
from
September 24, 2026 14:14
d3863b3 to
6fa5deb
Compare
…4223) * Downgrade "Invalid host" OpenAPI diagnostic to a warning Swagger 2.0 specs that use template placeholders (e.g. `{{hostname}}`) produce an "Invalid host" error from Microsoft.OpenApi because the value is not a valid URI host. The document itself still parses correctly. Treating this as a hard error blocks generation of specs like the ECE API that intentionally use placeholder values. Downgrading to a warning lets generation proceed while still surfacing the diagnostic. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add test and ECE fixture for template-host warning behaviour Covers the case where a Swagger 2.0 spec uses `{{hostname}}` as the `host` value. The fixture is stripped down from the real ECE spec to a single `/account` path so it stays minimal. The test asserts that `OpenApiReader` produces zero errors and at least one warning when it encounters the placeholder — confirming the downgrade added in the previous commit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
…4224) The "Invalid host" message for {{hostname}}-style placeholders in Swagger 2.0 specs is informational noise, not something a build author needs to act on. Emitting it as a hint rather than a warning keeps the warning count meaningful. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* Escape {{...}} in changelog-generated markdown to prevent substitution errors
A changelog entry whose title or description contains `{{hostname}}`
(or any double-brace template placeholder) triggers the substitution
parser when `ParseMarkdownStringAsync` re-parses the generated markdown.
Because the parser can't resolve the key, it emits an Error diagnostic.
That diagnostic's column is computed from the generated string, not from
the source file (`docs/release-notes.md`), so Errata crashes trying to
render a source label past the end of the line.
`RenderChangelogMarkdown` now replaces `{{` with `{{` before
returning. The HTML entity is invisible to the substitution parser
(which opens only on `{`), passes through Markdig as literal text, and
the browser decodes it back to `{{`. The visual output is unchanged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Use ChangelogPipeline to parse generated changelog markdown
Changelog markdown is generated from GitHub PR/issue titles and
descriptions, not authored in docs-builder source files. Running it
through the full docs-builder pipeline causes substitution keys, MyST
roles, and the diagnostic link validator to fire on content that was
never intended to carry any of that syntax — the {{hostname}} build
failure is the direct example.
A dedicated ChangelogPipeline strips all docs-specific parsers:
no UseSubstitution, no role parsers, no UseDiagnosticLinks. It keeps
the structural elements the renderer actually uses (headings, lists,
emphasis, autolinks, pipe tables, directives for dropdowns) and calls
DisableHtml so raw HTML in descriptions does not bleed into the output.
The earlier {{}} → { escape workaround in RenderChangelogMarkdown
is removed — it is no longer needed.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* Port API sitemap parity audit test to main The test lived only on the `test/api-sitemap-parity` branch. Bringing it to `main` keeps the audit reproducible without a branch switch. The test skips unless `FEATURE_ASSEMBLER_API_EXPLORER=true` is set, so it never runs in CI. Set that variable and point the assembler output at `.artifacts/assembly` to compare the local build against the Bump.sh production sitemap. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Migrate ApiSitemapParityTests to TUnit The xUnit-to-TUnit migration in #4182 missed this test, so it still used `[Fact]`, `Assert.Skip*`, and `TestContext.Current.CancellationToken`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Fail fast on invalid or empty sitemap in ApiSitemapParityTests Prevents a silent green pass when the sitemap endpoint returns an unexpected XML document (still HTTP 200). DownloadPageUrls now throws if the root element is not a urlset or sitemapindex in the expected namespace, and the test asserts the discovered URL set is non-empty. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add TODO noting ApiSitemapParityTests should be deleted post-migration References elastic/docs-eng-team#436. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
…4235) Made with ❤️️ by updatecli Co-authored-by: elastic-observability-automation[bot] <180520183+elastic-observability-automation[bot]@users.noreply.github.com>
Each API operation page emits 613 inline SVG elements in the sidebar nav, but they are only three distinct shapes (arrow, X, multi-operation branch). At ~246 bytes each on average, those duplicates account for ~151 KB per page — 89% of the 436 KB page weight. Three symbols are added to the hidden sprite sheet in `_GlobalLayout.cshtml`: `icon-api-arrow`, `icon-api-x`, and `icon-api-multi`. The templates that previously inlined the full path data now emit a single `<use>` reference per glyph instead. `currentColor` inheritance and the `rotate(180deg)` transform on GET arrows both work through `<use>` — the outer `<svg>` carries the transform. The same inline paths appear in `_HttpMethodBadge.cshtml` on API Explorer operation pages; those are updated to use the same sprites. `icon-chevron-double-down` is also added to the sprite sheet. It was referenced in `_TocTreeNavLegacy.cshtml:25` but missing — a pre-existing dangling reference that rendered as a blank icon. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Mpdreamz
force-pushed
the
fix/nav-svg-sprite
branch
from
September 29, 2026 10:01
6fa5deb to
71139c8
Compare
Member
Author
|
Closed to retarget to main as a standalone PR. Content preserved in new PR. |
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
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 three distinct SVG shapes rendered by
_NavHttpMethodGlyph.cshtmlwere being emitted as 613 separate inline elements per API operation page — 151 KB of duplicated markup per page, 389 KB of sidebar, and ~1.7 GiB of raw output across all 4,029 pages. Moving them to the existing sprite sheet cuts the sidebar to ~215 KB and the raw output by ~550 MB.Affects: Site UI, API reference
Prompt summary: Each API operation page contained 613 inline SVG copies of only 3 distinct shapes. The ask was to move those shapes into the page-level sprite sheet and replace the per-use inline SVG with
<use>references, following the same pattern already used by_TocTreeNav.cshtmland_NavSelect.cshtml.Why
_NavHttpMethodGlyph.cshtmlrendered the full SVG<path>string on every call — one call per nav item, with 200+ items per sidebar. Only three shapes exist: an arrow (GET/POST/PUT/PATCH), an × (DELETE), and a multi-op indicator. The page also had a dangling<use href="#icon-chevron-double-down"/>reference in_TocTreeNavLegacy.cshtmlthat pointed to a symbol that was not in the sprite sheet.What
Sprite sheet symbols
Four
<symbol>elements —icon-chevron-double-down,icon-api-arrow,icon-api-x, andicon-api-multi— are now in the hidden sprite<svg>in_GlobalLayout.cshtml. Theicon-chevron-double-downsymbol resolves the pre-existing dangling reference in_TocTreeNavLegacy.cshtml._NavHttpMethodGlyph.cshtmlEach branch now emits a single
<svg>with a<use href="#icon-api-…"/>reference instead of a full inline<path>. The inlinewidth="12" height="12"stays — the CSS rule at.nav-v2-api-method svgsets onlydisplay:block, so dropping the attributes would collapse the element to 300×150._HttpMethodBadge.cshtmlThe same two shapes appear on API operation page badges in
src/Elastic.ApiExplorer/. These now use the same sprite references. No CSS change is needed;.api-method-icon svgalready sizes explicitly.Verify
dotnet test tests/Navigation.Tests/Then build and open an API operation page locally to confirm method pills are coloured correctly and icons render at the right size in both light and dark mode.
Stack: 2 of 5, on top of #4206. #4208 follows.
🤖 Generated with Claude Code