Conversation
7fc4d25 to
8ab292d
Compare
Docs preview (local build)Handbook preview: https://docs-v3-preview.elastic.dev/elastic/docs-builder/pull/4138/ |
There was a problem hiding this comment.
Requesting changes: please add ICU support (or restore invariant mode in the build stage) so dotnet publish for the API image remains reliable on AL2023.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
| RUN chmod +x ./dotnet-install.sh | ||
| RUN ./dotnet-install.sh | ||
| RUN dnf update -y \ | ||
| && dnf install -y git clang nodejs22 nodejs22-npm |
There was a problem hiding this comment.
[HIGH] Missing ICU package can break dotnet publish in the build stage
DOTNET_SYSTEM_GLOBALIZATION_INVARIANT was moved to the runtime stage, so the build stage now runs dotnet publish in non-invariant mode. In this Dockerfile, the build-stage package install no longer includes libicu, which is required for globalization on AL2023 and can cause ./dev.sh build-api to fail during publish.
| && dnf install -y git clang nodejs22 nodejs22-npm | |
| RUN dnf update -y \ | |
| && dnf install -y git clang libicu nodejs22 nodejs22-npm |
There was a problem hiding this comment.
Approving — no new actionable findings.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
| EXPOSE 8080 | ||
| ENV ASPNETCORE_URLS=http://+:8080 | ||
| ENV ASPNETCORE_URLS=http://+:8080 \ | ||
| DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 |
There was a problem hiding this comment.
Can you explain what DOTNET_SYSTEM_GLOBALIZATION_INVARIANT does?
There was a problem hiding this comment.
some info here https://learn.microsoft.com/en-us/dotnet/core/runtime-config/globalization
But basically I had to move the env as it was in another stage, and needed here for the build
Running ./dev.sh serve-api starts the docs API at http://localhost:8081 without requiring a local .NET SDK install. ./dev.sh build-api builds only the API image; extra flags pass through to bake. Also aligns the API Dockerfile with the improvements made to the MCP Dockerfile: consolidate dnf layers into one RUN, install Node 22 from the AL2023 nodejs22/nodejs22-npm packages instead of dnf npm (Node 18), move DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 to the runtime stage only, and clean up the dotnet-install.sh workaround comment. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Extends the dev Docker setup introduced in c7c3ace to cover the MCP server. Running `./dev.sh serve-mcp` starts the MCP HTTP server at `http://localhost:8080/docs/_mcp` without requiring a local .NET SDK install. `./dev.sh build-mcp` builds only the MCP image; extra flags (e.g. `--progress=plain`, `--no-cache`) pass through to bake. The MCP server uses its own production Dockerfile at `src/api/Elastic.Documentation.Mcp.Remote/Dockerfile`. Three bugs in that file were fixed along the way: `npm` installed Node 18 from dnf while Playwright requires Node 20+, `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1` was set in the build stage (causing the regex source generator to reject the `"en-US"` culture name), and the publish command hardcoded `linux-x64` regardless of the builder's native architecture. Node is now copied from `node:22-bookworm-slim`, the invariant flag moved to the runtime stage only, and a `PUBLISH_RID` build arg controls the target RID — defaulting to `linux-x64` for CI, falling back to `TARGETARCH` when empty (so Apple Silicon builds `linux-arm64` natively via bake). The OTel package bump in `Directory.Packages.props` is a forward-port of the fix from the `fix/otel-resources-host-vulnerability` branch: the MCP server's restore fails without it due to `NU1903` on `OpenTelemetry.Resources.Host` 1.15.1-beta.1. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…on.Api
Replace the custom PUBLISH_RID build arg and case-statement with the same
arch=$TARGETARCH / if amd64 → x64 / RID="${TARGETOS}-${arch}" pattern used
in src/api/Elastic.Documentation.Api/Dockerfile. Docker buildx always
populates TARGETARCH and TARGETOS correctly for both CI and local builds,
so the override arg was not needed.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…de image AL2023 ships nodejs22 and nodejs22-npm packages, so there is no need for a separate node:22-bookworm-slim stage and the COPY/symlink dance. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Running ./dev.sh serve-api starts the docs API at http://localhost:8081 without requiring a local .NET SDK install. ./dev.sh build-api builds only the API image; extra flags pass through to bake. Also aligns the API Dockerfile with the improvements made to the MCP Dockerfile: consolidate dnf layers into one RUN, install Node 22 from the AL2023 nodejs22/nodejs22-npm packages instead of dnf npm (Node 18), move DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 to the runtime stage only, and clean up the dotnet-install.sh workaround comment. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
8bae65b to
31facc8
Compare
Extends the dev Docker setup to cover the docs API. Running
./dev.sh serve-apistarts the API athttp://localhost:8081without a local .NET SDK install../dev.sh build-apibuilds only the API image; extra flags pass through to bake.Affects: Dev tooling
Stack: 2 of 2, on top of #4132
Why
The docs API had no dev workflow equivalent to
./dev.sh serve-mcp. Developers needed a local .NET SDK to run and test it.What
API bake target and compose service
A new
apitarget indocker-bake.hclpoints at the production Dockerfile. A matchingapiservice andapi-artifactsvolume are added todocker-compose.yml. The service maps host port8081→ container port8080to avoid conflicting with the MCP server.dev.sh commands
build-api,serve-api,serve-api-detached, andstop-apifollow the same conventions as the existing MCP commands.API Dockerfile alignment
The Dockerfile is updated to match the improvements already applied to the MCP Dockerfile: dnf layers consolidated, Node installed from the AL2023
nodejs22/nodejs22-npmpackages instead of the oldernpmpackage (Node 18),DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1moved to the runtime stage only, and thedotnet-install.shworkaround comment cleaned up.Verify
./dev.sh build-api ./dev.sh serve-api # API available at http://localhost:8081🤖 Generated with Claude Code