Pin the font the layout suite measures, and let the slice say it means plaintext
ci / build and test (push) Failing after 42s
ci / api image (push) Skipped
ci / android head (push) Failing after 5s

Two failures left on the runner, with nothing in common except that both only appear on a
machine unlike the one anybody develops on. The runner is Alpine, musl, inside a container,
with no fonts installed at all — and that combination is now reproducible locally, which is
how these were fixed rather than guessed at. Both are verified by running the suite in it.

The layout suite had two causes stacked, and the first hid the second completely. Missing
libfontconfig stops libSkiaSharp loading, which the last commit fixed and which then
revealed the real one: Avalonia takes its default font family from the platform, and on an
image with no fonts there is no answer, so FontManager throws "Default font family name
can't be null or empty" inside AppBuilder.SetupUnsafe — before a single test body runs, for
all sixty-eight of them, naming none of their subjects. WithInterFont does not prevent it:
it registers a collection without nominating a default. HeadlessApp's own comment already
claimed it measured "the same Inter font the application registers", which was an intention
the code never carried out.

Both heads now name it, through FontManagerOptions.DefaultFamilyName. That is worth more
than getting CI green: a suite whose entire job is measuring text was taking its metrics
from whatever the machine happened to have — Segoe UI here, DejaVu there — and reporting
the two as one number. It also means the application uses the font it has been shipping and
declining to use since it first referenced the package; almost nothing moves visually,
because App.axaml already sets MonoFont on essentially everything that draws.

The end-to-end slice was the product being right and the test leaning on an accident.
ServerConnection permits an http authority only when it is loopback. Testcontainers reports
the host a container can actually be reached at, so running the suite directly gives
localhost and passes, while running it inside a container gives the bridge gateway
172.17.0.1 and is refused — correctly, since a client that accepted plaintext metadata from
a routable address would be a weakness for everyone who is not a test. Loosening that rule
was the wrong repair. The slice now passes configureOidc and says out loud that it accepts
plaintext from the Keycloak it started itself.

Verified by reproducing the runner rather than approximating it: dotnet/sdk:10.0-alpine,
musl-x64, fc-list returning zero, the docker socket mounted so Testcontainers resolves the
gateway exactly as it does in CI. The whole solution passes there — 19 suites, 0 failures,
4 skipped — and the end-to-end failure was confirmed causal by reverting only that one file
and watching it fail again in the same container. The layout suite also still passes on a
Fedora desktop with 595 fonts, so the two agree now.

Not verified on Windows, and it should be said plainly rather than left to be discovered:
pinning the family changed the measured metrics there too, so a tight layout assertion
could have moved. platform-flags.md records that, and corrects the entry the last commit
added — "libfontconfig, and nothing else" was true of the container it was tested in and
false of the runner.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-01 14:48:30 +02:00
co-authored by Claude Opus 5
parent 208aca1191
commit cf1a321d1e
4 changed files with 84 additions and 10 deletions
@@ -61,8 +61,21 @@ public sealed class M1VerticalSliceTests(DevStack stack) : IClassFixture<DevStac
var account = DevStack.RealmUser;
var browser = new ScriptedBrowser(account.Username, account.Password);
using var connection = await ServerConnection
.SignInAsync(stack.ApiBaseUrl, browser, TimeProvider.System, Token);
// The plaintext exemption is stated here rather than inferred from the address, and that is the
// whole point of stating it. ServerConnection allows an http authority only when it is loopback,
// which is a sound rule and not one this suite can rely on: Testcontainers reports the host it
// can actually be reached at, so a developer running the tests directly gets localhost and passes,
// while the same suite inside a container gets the bridge gateway — 172.17.0.1 — and is refused.
// That is the product being right. 172.17.0.1 is not loopback, and a client that quietly accepted
// plaintext metadata from a routable address would be a real weakness for everyone who is not a
// test. So the test says out loud that it accepts plaintext from the throwaway Keycloak it started
// itself, and the rule stays as strict as it was for everybody else.
using var connection = await ServerConnection.SignInAsync(
stack.ApiBaseUrl,
browser,
TimeProvider.System,
Token,
configureOidc: options => options with { RequireHttpsMetadata = false });
AssertDiscoveredFromTheServer(connection);