[docs] Document hostname inheritance for Ingress paths and Gateway routes - #1574
aspire-repo-bot[bot] wants to merge 1 commit into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
David Pine (IEvangelist)
left a comment
There was a problem hiding this comment.
🤖 Automated docs-accuracy review — PR #1574
Source of truth: microsoft/aspire@main @ 1cdf7d17248ae78ee018abbc314f772ace5e624d — contains source PR microsoft/aspire#19430 (merge 6785869656, "Fix Kubernetes hostname publishing and routing").
⚠️ Branch mismatch (non-blocking). This PR targetsrelease/13.6, which does not exist inmicrosoft/aspire. Verified againstmain(milestone 13.6), which contains the change. The13.6-onward version claim is corroborated below.
Phase A — claims: 7 non-narrative claims → 6 verified · 1 verified-with-nuance · 0 contradicted · 0 unverifiable.
Phase B — doc-tester: exercised /deployment/kubernetes-ingress/ → HTTP 200, 0 console errors/warnings; insertion region + reused components (Tabs, titled code, <Aside>) render; no new links/components. Knowledge gap: local build predates this PR.
Verdict: 🟡 COMMENT
The behavior — hostless-path/route hostname inheritance, explicit-hostname precedence, default-backend catch-all + TLS-compat rule, and the 13.6-onward attribution — is all verified against source. One minor nuance worth flagging (multi-hostname behavior); nothing blocking.
Phase A — Claim verification
✅ Version framing is accurate this time
Unlike the DevTunnel note (#1570), the 13.6-onward claim here checks out precisely:
- The inheritance logic (
AddPathForHost/ResolveHostnamesAsyncinKubernetesEnvironmentResource.cs) is present onmainonly and is absent fromrelease/13.5, which still usespathsByHost = ingressResource.Paths.GroupBy(p => p.Host ?? string.Empty)— i.e., hostless paths → empty host → catch-all. That exactly matches the doc's "in earlier versions, hostless paths and routes were generated as catch-all rules." upstreamnow carries GA tags v13.5.0–v13.5.3; there is still no v13.6 tag (13.6 is the currentmainmilestone). Since 13.5.x GA lacks the change and it lives on the 13.6 milestone, "from Aspire 13.6 onward" is correct.
ℹ️ Nuance worth flagging (non-blocking) — multi-hostname fan-out & Gateway limit
WithHostname(...) can be called more than once. When it is, a single hostless path/route is emitted once per configured hostname, not merged into one rule. The source snapshot AddIngress_WithHostname_AppliesToHostlessPath sets two hostnames and produces the /api path under both api.example.com and www.example.com. Additionally, for Gateways, a hostless route inheriting more than 16 hostnames throws (HttpRouteHostnameLimit, pointing users to explicit WithRoute(hostname, path, endpoint)). The doc's singular "set the hostname once and reuse it" framing is correct for its single-hostname example, but a one-line note about the multi-hostname fan-out (and the Gateway 16-hostname cap) would make the section complete. Optional.
Claim verdicts (7) with evidence, against microsoft/aspire@1cdf7d17
| # | Type | Claim | Verdict & evidence |
|---|---|---|---|
| C1 | api-shape | WithHostname(...) exists on Ingress & Gateway (incl. string overload) |
verified — api/Aspire.Hosting.Kubernetes.cs: Ingress L150/L153, Gateway L99/L102. |
| C2 | api-shape | WithPath/WithRoute exist, incl. host-scoped WithPath(host, path, endpoint) / WithRoute(host, path, endpoint) |
verified — WithPath L168 & L171; WithRoute L105 & L108. |
| C3 | api-behavior | WithHostname(...) applies to hostless WithPath/WithRoute (they inherit the hostname) |
verified-with-nuance — hostless path → foreach (hostname in resolvedHostnames) AddPathForHost(hostname, path); Gateway → httpRoute.Spec.Hostnames.AddRange(resolvedHostnames). Snapshots AddIngress_WithHostname_AppliesToHostlessPath, AddGateway_WithHostname_AppliesToHostlessRoute. Nuance: multi-hostname fan-out (one rule per hostname) + Gateway HttpRouteHostnameLimit (16) not mentioned. |
| C4 | api-behavior | An explicit per-path/route hostname takes precedence over WithHostname(...) |
verified — if (path.Host is { } explicitHost) AddPathForHost(explicitHost, path); (explicit branch first). Test AddIngress_WithHostAndPath_GeneratesHostRule. |
| C5 | api-behavior | WithDefaultBackend(endpoint) stays a catch-all (no host) incl. the TLS compatibility rule |
verified — comment "A default backend remains catch-all even when hostnames are configured. Only synthesize host rules for TLS…"; guard DefaultBackend is not null && Tls.Count > 0. Tests AddIngress_HostnameWithDefaultBackendWithoutTls_DoesNotGenerateHostRule + AddIngress_TlsWithDefaultBackend_AutoGeneratesHostRule. |
| C6 | api-shape | WithTls() (parameterless) exists on Ingress |
verified — api/...cs L180 (parameterless; string/Parameter overloads L174/L177). |
| C7 | version / api-behavior | Inheritance applies "from Aspire 13.6 onward"; earlier versions were catch-all | verified — logic on main only; absent from release/13.5 (retains GroupBy(p => p.Host ?? string.Empty)). No v13.6 tag yet; change on main milestone 13.6; 13.5.x GA lacks it. |
Phase B — doc-tester report
Focus: new "Hostname inheritance for paths and routes" section · Route: http://localhost:51482/deployment/kubernetes-ingress/ · Tester: doc-tester skill (blind-user; no source reading).
| Category | Passed | Failed | Warnings |
|---|---|---|---|
| Content accuracy (rendered) | n/a | 0 | 0 |
| Components / rendering | 3 | 0 | 0 |
| Links | 0 new | 0 | 0 |
Critical issues: none. Warnings: none.
Passed checks
- Page health:
GET /deployment/kubernetes-ingress/→ 200, title "Expose services with Ingress and Gateway API | Aspire". 0 console errors, 0 warnings. - Insertion region intact: new H2 sits between "Routing paths to services" and "## TLS and certificates" (
#tls-and-certificates, renders). The preceding paragraph already documents the host-scopedWithPath("api.example.com", "/", endpoint)overload andWithDefaultBackend(endpoint)— the exact APIs the new section elaborates. - Code shape already renders: the page already shows
.WithHostname("app.example.com").WithTls();andingress.WithPath("/api", …)/ingress.WithPath("/", …)in titled Tabs — identical to the new example ⇒ zero render risk. - Components reused, none new: the new
<Aside type="note">maps to the already-rendering "Note" complementary; Tabs + titled code figures already render. - Links: added prose has no new links.
Knowledge gap — running build predates PR #1574
- The local frontend doesn't contain this change, so the literal new section couldn't be rendered. I validated page health, the insertion anchors, that the new section's code shape + Aside/Tabs already render on this page, and that no new links/components are introduced. Reused-pattern, no-link addition ⇒ render failure effectively impossible.
Automated review · Phase A read microsoft/aspire@main 1cdf7d17 (source of truth = upstream) · Phase B via doc-tester (blind-user, Playwright).
Adam Ratzman (adamint)
left a comment
There was a problem hiding this comment.
No issues from this review.
Alistair Matthews (alistairmatthews)
left a comment
There was a problem hiding this comment.
Some rewording suggestions for clarity.
| `WithHostname(...)` on the Ingress or Gateway sets the hostname that applies | ||
| to any path (`WithPath`) or route (`WithRoute`) you add **without** an | ||
| explicit hostname of its own. This lets you set the hostname once and reuse it | ||
| across every hostless path or route: |
There was a problem hiding this comment.
| `WithHostname(...)` on the Ingress or Gateway sets the hostname that applies | |
| to any path (`WithPath`) or route (`WithRoute`) you add **without** an | |
| explicit hostname of its own. This lets you set the hostname once and reuse it | |
| across every hostless path or route: | |
| The `WithHostname()` method on the Ingress or Gateway sets the hostname that applies | |
| to any path or route you add **without** an | |
| explicit hostname of its own, by using `WithPath` or `WithRoute`. This arrangement lets you set the hostname once and reuse it across every hostless path or route: |
| If a path or route specifies its own hostname — via the host-scoped | ||
| `WithPath("api.example.com", "/", endpoint)` overload, or the equivalent on | ||
| `WithRoute` — that explicit hostname takes precedence over the one from | ||
| `WithHostname(...)`. |
There was a problem hiding this comment.
I think this will be clearer if we disentangle the clauses:
| If a path or route specifies its own hostname — via the host-scoped | |
| `WithPath("api.example.com", "/", endpoint)` overload, or the equivalent on | |
| `WithRoute` — that explicit hostname takes precedence over the one from | |
| `WithHostname(...)`. | |
| If a path or route specifies its own hostname, that explicit hostname takes precedence over the one from `WithHostname()`. You can specify the hostname by using the host-scoped | |
| `WithPath("api.example.com", "/", endpoint)` overload, or the equivalent on | |
| `WithRoute` . |
| `WithDefaultBackend(endpoint)` is unaffected by `WithHostname(...)`: the | ||
| default backend always generates a catch-all rule (no `host` restriction) so | ||
| it keeps accepting any traffic that doesn't match a more specific path or | ||
| route, including the TLS compatibility rule Aspire generates for it. |
There was a problem hiding this comment.
| `WithDefaultBackend(endpoint)` is unaffected by `WithHostname(...)`: the | |
| default backend always generates a catch-all rule (no `host` restriction) so | |
| it keeps accepting any traffic that doesn't match a more specific path or | |
| route, including the TLS compatibility rule Aspire generates for it. | |
| `WithDefaultBackend(endpoint)` is unaffected by `WithHostname(...)`: the | |
| default backend always generates a catch-all rule, no `host` restriction. Thus | |
| it keeps accepting any traffic that doesn't match a more specific path or | |
| route, including the TLS compatibility rule Aspire generates for it. |
…ps (#1780) ## Summary <!-- Describe what this pull request changes and why. --> Reconcile the 13.6 wiki audit and **all 25 open `docs-from-code` proposals targeting `release/13.6`** against the actual release source. Add missing canonical guidance rather than putting all coverage in What's new. This is a new, isolated feature PR into `release/13.6`; it does not update the release rollup #1599, merge or close another proposal, or push directly to a release branch. **Draft with explicit remaining packaging/validation gates:** the six REPL walkthroughs are source-verified, but current publicly available 13.6 packages do not contain the late `WithRepl` exports. Generated API catalogs have deliberately not been fabricated or refreshed from 14.x. See the open checklist below. ### Evidence baseline - Documentation base: `717442f6666948bcf77f3d704dc2dadf7c080ec2`. - Product source of truth: [`microsoft/aspire@e8fd6fbb954f50ccd2e66479538392f65e13e71d`](https://github.com/microsoft/aspire/tree/e8fd6fbb954f50ccd2e66479538392f65e13e71d), current `release/13.6` at audit time. Source was read from that Git object, not the stale source working directory. - [13.6 wiki](https://github.com/microsoft/aspire/wiki/13.6-Change-log) snapshot `8e01a371d4f16a1306e48174d4cf1fdeca714348`, whose cutoff is product PR 20511. Later backports 20541/20546/20548 are included here. - Proposal base branches alone were **not** used as proof of release membership. Direct ancestry and known release backports were checked. Four fallback-targeted proposals are excluded below. - Wiki link corrections: its REPL link #1752 actually covers Sandboxes; the REPL proposal is #1740. Its AOT link #1714 covers PFX certificates, not AOT. ### Complete audit-gap checklist Checked items mean documentation coverage is implemented, not that cloud deployment or every product runtime scenario was executed. - [x] **1. Dotnet API graduation:** correct removal to **13.6**, not 14.0, in What's new, both Dotnet guides, and the diagnostic page; preserve the prerelease package caveat. This applies to core `AddDotnetProject`, `DotnetProjectResource`, and related `WithBuildEnvironment` overloads, not all uses of the diagnostic. Source: microsoft/aspire#20496. - [x] **2. Sandboxes:** remove obsolete API suppressions in the article and deployment guide while preserving Azure service preview/access and prerelease package limitations. Source: microsoft/aspire#20483. - [x] **3. Docked REPL documentation:** all six PostgreSQL/MySQL/MongoDB/SQL Server/Redis/Valkey guides plus the article now cover opt-in `WithRepl`/`withRepl`, run-only availability, actual client privileges, credential handling, and explicit exit versus closing a viewer. Source: microsoft/aspire#20419, backport of microsoft/aspire#20231. Package-backed checks remain open below. - [x] **4. Terminal CLI flag:** update current 13.6 article, `with-terminal`, and all three terminal command references. Preserve `terminals.v1` and experimental hosting API distinctions. Current configuration/schema data had no flag entry to remove; historical 13.5 notes remain historical. Source: microsoft/aspire#20548. - [x] **5. First-party Rust:** rewrite both canonical Rust guides around `Aspire.Hosting.Rust`; document Cargo versus application arguments, typed targets, debugging, generated Dockerfiles, workspace context, ABI constraints, and Toolkit migration. Bacon remains explicitly Toolkit-only. Add exact first-party package mapping. Source: microsoft/aspire#18906 and current Rust README. - [x] **6. Agent setup:** align command reference, skills guide, AI-agent guide, and article on MCP opt-in, `--mcp`, chained/non-interactive behavior, seven-skill catalog, Project v2 migration, and Copilot app detection. Also fix stale default-selection text: all applicable bundle skills are preselected; companion tools remain opt-in. Sources: microsoft/aspire#19893, microsoft/aspire#20405, microsoft/aspire#19820. - [x] **7. Deno AppHost runtime:** document Deno 2+ detection, commands, permissions, native watch/type checking, doctor, and `DENO_CERT`, separately from Deno guest hosting. Source: microsoft/aspire#18627, distinct from microsoft/aspire#18628. - [x] **8. Native AOT / Fluent UI v5:** concise article, dashboard exploration, and standalone guidance; automatic packaged-dashboard selection, no invented performance figures. Source: microsoft/aspire#19565 and release packaging sources. - [x] **9. NuGet:** document bundled in-process operations, credential providers, non-interactive authentication, and realistic troubleshooting. Correct the proposal's `dotnet nuget locals` authentication advice: cache commands do not authenticate a feed. Source: microsoft/aspire#20391. - [x] **10. Multithreaded builds:** article and coordinated-build guide explain `-mt`, SDK detection, distinct project/file-based SDK floors, and fallback. Source: microsoft/aspire#20441. - [x] **11. Radius:** add a real deployment guide with C#/TypeScript setup, recipe-backed connections versus local endpoints, per-resource credential behavior, unauthenticated Redis limitation, secret exposure boundaries, and actionable runtime diagnostics 070–091. Wire navigation and exact package mapping. Source: microsoft/aspire#19555 and release README. - [x] **12. Connection aliases:** replace contradictory no-encoding guidance, retain composed logical-key-first lookup and portable-target behavior, explain collision detection and custom-publisher metadata. Source: microsoft/aspire#19729. - [x] **13. Connector Namespace / Toolbox / provisioning:** add Connector Namespace walkthrough, security/consent/revocation limits and mapping/sidebar; add Foundry Toolbox walkthrough, connection properties, roles, index prerequisites, approval enforcement boundaries, immutable versions, and existing-resource behavior. Extend existing Azure provisioning guide without a duplicate page. Sources: microsoft/aspire#19024, microsoft/aspire#17742, microsoft/aspire#20131. - [x] **14. Remaining high-impact items:** article covers opt-in manifest-aware DNX and new-template CLI bundling (existing SDK guides retained), migration skill and Copilot app detection; canonical inline `CsiVolumeSourceV1`/`VolumeV1.Csi` example, management links, Cosmos vNext telemetry, and AI Inference `GetModelInfoAsync`/`/info` health checks with `DisableHealthChecks`. No Azure OpenAI health-check claim. Sources: microsoft/aspire#19310, microsoft/aspire#19076, microsoft/aspire#19826, microsoft/aspire#20070, microsoft/aspire#15671, microsoft/aspire#15969. - [x] **15. All 25 proposal dispositions:** listed below, including newer dashboard backports and four exclusions. Existing Sandbox inference coverage is retained rather than copied from a stale draft. - [ ] **16. Refresh generated API/catalog/Twoslash data from an official post-backport 13.6 build.** Existing `26473.12`/`a11eca96` data remains untouched. The newest public `dotnet9` feed package checked, `13.6.0-preview.1.26474.10` at `43496a2a306c81c862c947b11b4f4e5494b6fe08`, still has no Redis `WithRepl` in its actual package XML. Do not use 14.x, hand-edit declarations, or attribute source changes to older binaries. - [ ] **Validate the six REPL examples against that actual post-backport SDK and running clients.** Their new TypeScript fences are plain TypeScript, not annotated with unsupported Twoslash data. No existing diagnostics are allowlisted or suppressed; no generated API exports are fabricated. Enable Twoslash when the genuine catalog catches up. ### All 25 open proposal dispositions and provenance Text is selectively adapted from these proposals, not merged wholesale. #1778 and #1748 are authored by @sebastienros; the other proposals are authored by the Aspire repo bot. The table credits the associated product-change authors where supplied by the proposals. Existing PRs remain open and unchanged. | Docs PR | Release source / credited product author | Disposition | | --- | --- | --- | | #1778 | microsoft/aspire#19729 — @sebastienros | **Adopted:** canonical connection-string alias correction, including logical-first resolution and migration. | | #1771 | microsoft/aspire#20481 — @sebastienros | **Excluded:** flat polyglot feature keys are not in the audited release tip; no verified backport. Preserve release key names. | | #1770 | microsoft/aspire#20525 → microsoft/aspire#20548 — @mitchdenny | **Corrected/adopted:** command guides plus the still-current 13.6 article, which the proposal incorrectly treats as historical. | | #1769 | microsoft/aspire#20416 — @JamesNK | **Excluded:** brand hover change has no verified 13.6 membership/backport. | | #1768 | microsoft/aspire#20523 → microsoft/aspire#20546 — @JamesNK | **Adopted:** run pin/unpin preserves selector and current selection. | | #1766 | microsoft/aspire#20537 → microsoft/aspire#20541 — @mitchdenny | **Adopted:** terminal dock empty state. | | #1761 | microsoft/aspire#20490 → microsoft/aspire#20496 — @eerhardt | **Corrected:** graduation is 13.6, package remains prerelease, Blazor-specific exception retained. | | #1760 | microsoft/aspire#20436 — @eerhardt | **Excluded:** CLI net11/tools-any retarget is not in the audited release; no fallback-base inference. | | #1748 | microsoft/aspire#20131 — @sebastienros | **Adopted:** extend existing provisioning guide with service-specific models/lookups and projection limits. | | #1744 | microsoft/aspire#20337 → microsoft/aspire#20441 — @karolz-ms | **Adopted:** precise SDK-conditional multithreaded build coverage. | | #1740 | microsoft/aspire#20231 → microsoft/aspire#20419 — @mitchdenny | **Adapted:** all six guides; TypeScript-first tabs, source-verified lifecycle/security. Actual post-backport SDK/runtime gate is open above. | | #1738 | microsoft/aspire#20158 → microsoft/aspire#20405 — @karolz-ms | **Partly already covered / completed:** existing seven-skill catalog retained; add project migration guidance and correct command catalog/defaults. Do not misclassify the bundled skill as a companion tool. | | #1735 | microsoft/aspire#20334 — @karolz-ms | **Excluded:** enhanced startup errors are not in the audited release; no verified backport. | | #1731 | microsoft/aspire#19847 → microsoft/aspire#20391 — @eerhardt | **Corrected/adopted:** in-process NuGet and real authenticated-restore troubleshooting, not cache-command authentication. | | #1719 | microsoft/aspire#20299 → microsoft/aspire#20407 — @JamesNK | **Corrected/adopted:** cookie naming/scoping; identical names can collide but do not guarantee cross-dashboard cookie decryptability or shared sign-in. | | #1664 | microsoft/aspire#20011 — @maddymontaquila | **Adopted:** concise Azure environment icon release note. | | #1628 | microsoft/aspire#17742 — @davidfowl | **Adapted/expanded:** canonical Toolbox examples, consumer contract, role/index prerequisites, approval/security and concurrency limits. | | #1623 | microsoft/aspire#19810 — @mitchdenny | **Already covered:** current Sandbox guide/article already describe compute inference, explicit selection and external endpoints. Preserve that guidance while removing obsolete suppressions. | | #1620 | microsoft/aspire#19243 — @sebastienros | **Adapted:** AKS credential-before-Helm cleanup and destructive-operation warning; omit misleading ambient-context workaround. | | #1614 | microsoft/aspire#19870 — @sebastienros | **Adopted:** typed callback handle behavior in extension authoring and article. | | #1574 | microsoft/aspire#19430 — @mitchdenny | **Adapted:** canonical hostname inheritance, explicit-host precedence, catch-all default backend. | | #1570 | microsoft/aspire#19590 — @karolz-ms | **Adopted:** Dev Tunnel URL regression troubleshooting. | | #1565 | microsoft/aspire#19429 — @mitchdenny | **Corrected/adopted:** Helm embedded parameters with real `refExpr` and `addParameter(name, { value })`, not stringifying a handle or using an invalid actual-SDK overload. | | #1564 | microsoft/aspire#19026 — @karolz-ms | **Corrected/adopted:** C#/TypeScript Dotnet gateway walkthrough. Retain both experimental diagnostics; remove obsolete run-only restriction after microsoft/aspire#19997 publishing support. Avoid imported ambiguous API reference. | | #1499 | microsoft/aspire#19248 — @IEvangelist | **Adopted:** describe exact secret-value redaction and embedded-secret limit; release article already covered the fix. | ### Important source-verified corrections to proposals / earlier audit assumptions - [`BlazorGatewayExtensions.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Hosting.Blazor/BlazorGatewayExtensions.cs): `AddDotnetProjectBlazorGateway` and the Dotnet `WithBlazorClientApp` overload still carry `ASPIREDOTNETPROJECT001`; the class carries `ASPIREBLAZOR001`. They share `WithBlazorClientAppCore`/`WithBlazorApp` and the publish-companion path. Thus neither blanket diagnostic retirement nor the proposal's old run-only claim is correct. - [`SkillDefinition.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Cli/Agents/SkillDefinition.cs) sets bundled skills' `IsDefault=true`; [`AgentInitCommand.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Cli/Commands/AgentInitCommand.cs) selects the applicable catalog defaults for both flows. MCP has its own standalone-only binding. - [`TypeScriptAppHostToolchainResolver.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Cli/Projects/TypeScriptAppHostToolchainResolver.cs) is the source for Deno flags and certificate variable; guest Deno hosting is separate. - [`Radius README`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Hosting.Radius/README.md) supplies the resource-specific credential rules and publish diagnostics, not assumptions about local endpoints. ## Third-party links and affiliations <!-- List third-party links and disclose material affiliations. --> Links point to official Microsoft Learn, VS Code Marketplace debugger extensions, Rust/Cargo/Bacon documentation, Radius documentation, and source repositories. No sponsorship, commercial endorsement, or affiliation claim is introduced. Maintainers should supply any personal affiliation disclosure required by policy; automation has not inferred one. ## Validation <!-- List the checks you ran or explain why validation isn't needed. --> - **97 passing focused unit checks** across API-reference authoring/rendering, Twoslash blocks, file-tree formatting, CLI configuration schema, SEO lengths, and resource catalog. - **82 passing structured-data checks**, including exact integration mapping uniqueness and page resolution. - **11 C# samples compile**, zero warnings/errors, using genuine `13.6.0-preview.1.26473.12` packages. Scope: Rust, Connector Namespace, Radius, Toolbox, inline CSI, Helm, Blazor gateway, and provisioning. `Projects.Api/Worker/Client` use compile-only `IProjectMetadata` stand-ins; no claim of running those apps or provisioning cloud resources. - **10 TypeScript samples pass `tsc`** under `strict`, `NodeNext`, and `ES2022` against three **unmodified actual SDK files**, not just the site's declaration bundle. The fixture uses the exact `e8fd6fbb` release `AtsCapabilityScanner` and genuine `26473.12` TypeSystem/code-generator/integration binaries, whose informational source is `a11eca96`. This is an isolated local generation fixture, **not** a claim that official CLI generation or a new packaged release was tested. An attempted restore with the older handed-off local CLI could not discover an AppHost server; the bounded direct generator fixture was used instead. - The SDK scan is **not globally warning-free**: it reports a Radius `withContainerImage` collision on `CSharpAppResource` and an App Configuration `createRoleAssignment` overload collision. None of the compiled examples calls those colliding methods; the warnings are retained in evidence, not suppressed, and no generated declarations were edited. - Browser: Connector Namespace, Radius, both Rust pages, Foundry hosting, and What's new return **HTTP 200**, correct headings, and no rendered Twoslash errors. New guide/article page-local anchors and the cross-page Blazor anchor resolve. Connector/Radius mobile layouts have no horizontal overflow; Connector language-tab interaction works. Standalone Astro preview emits expected `/api/live` 404s because StaticHost is not running. - `git diff --check` passes. No production `pnpm build`, cloud deployment, REPL runtime session, full product suite, or blanket validation of every pre-existing example was performed. - Generated C#/TypeScript API data, declaration bundles, integration catalogs, image catalogs, and contributor data are unchanged. Only the authored package-to-guide mapping is updated. **Before merging:** complete the two packaging/REPL checkboxes above, inspect CI, and obtain human review. This PR intentionally does not close or merge the source documentation proposals. --------- Co-authored-by: David Pine <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Documents changes from microsoft/aspire#19430
@mitchdennyTargeting
release/13.6based on the source PR milestone13.6.Why
microsoft/aspire#19430 fixes Kubernetes hostname publishing and routing:
WithHostname(...)on anAddIngress/AddGatewaynow applies to hostlessWithPath/WithRoutecalls instead of leaving them as catch-all rules, whileWithDefaultBackend(endpoint)keeps generating a catch-all rule as before. The PR body's "User-facing usage" section shows this new scoping behavior in both C# and TypeScript AppHost samples, which triggered thepr_body_has_user_facing_sectionsignal — the existing docs describeWithHostname/WithPath/WithDefaultBackendbut didn't previously explain this inheritance rule.What changed
src/frontend/src/content/docs/deployment/kubernetes-ingress.mdx: added a new "Hostname inheritance for paths and routes" section after the path-routing example, explaining thatWithHostname(...)now scopes hostless paths/routes, that explicit per-path/route hostnames still take precedence, and thatWithDefaultBackend(...)remains an unscoped catch-all (including its TLS compatibility rule). Includes a version note that this inheritance behavior applies from Aspire 13.6 onward.No new pages were created; this is a targeted addition to the existing Ingress/Gateway walkthrough page since the behavior applies to both
AddIngressandAddGateway(the Gateway-specific AKS walkthrough already links back to this page for the shared concepts).