Add test to verify sample AppHost publish manifests

[IEvangelist]

Summary

Adds a test that generates the Aspire publish manifest for each project-based sample AppHost and compares it against a committed aspire-manifest.json snapshot, so any change that affects publish output is caught in CI. Closes #572.

As noted in the issue, this is the cheapest way to get coverage of publish output: any change that impacts a manifest now requires the committed "expected" manifest to be regenerated, which surfaces the change in the diff for review.

What's included

• tests/SamplesIntegrationTests/ManifestTests.cs — a theory over every *.AppHost.dll referenced by the test project (12 AppHosts).
• Expected manifests — aspire-manifest.json committed next to each AppHost (9 new, 3 stale ones refreshed). This matches the existing manifest launch profile / GenerateAspireManifest convention of writing the manifest into the AppHost directory.
• .gitignore — ignores the transient aspire-manifest.g.json the test generates.

How it works

• Generates each manifest in-process with DistributedApplicationTestingBuilder using --operation publish --publisher manifest — no Docker required.
• Writes the manifest into the AppHost's own directory so all paths in the manifest (project references, bind mounts, generated bicep/Dockerfiles) are machine-independent relative paths (e.g. ../Foo/Foo.csproj).
• Normalizes the only machine-specific token — the volume-name SHA‑256 prefix (derived from the absolute AppHost path) — to a <sha256> placeholder, plus line endings.
• Neutralizes ambient configuration during generation (the Metrics sample bakes ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL / AppHost:OtlpApiKey into a container's environment) so manifests are reproducible regardless of a contributor's environment or user secrets, and so an OTLP API key can never leak into a committed snapshot.
• Cleans up generated byproducts (aspire-manifest.g.json, *.module.bicep, *.Dockerfile) without ever deleting committed source files.
• Runs in its own non-parallel xUnit collection so it doesn't race with the Docker-based AppHost tests.

Regenerating the expected manifests

When a change intentionally affects a manifest, regenerate locally and commit the result:

# PowerShell
$env:ASPIRE_UPDATE_MANIFESTS='true'; dotnet test --filter "FullyQualifiedName~ManifestTests"

# bash
ASPIRE_UPDATE_MANIFESTS=true dotnet test --filter "FullyQualifiedName~ManifestTests"

Update mode is refused when CI is set, so the verification can never be silently skipped on CI. The failure message points contributors at these steps.

Notes for reviewers

• The expected manifests were generated on Windows; manifest paths use forward slashes and all machine-specific tokens are normalized, so they match Linux CI output. CI runs the test suite on ubuntu-latest.
• A few resources legitimately emit {"error":"This resource does not support generation in the manifest."} (Docker Compose environment / custom resources). That's the current publish output and is snapshotted as-is for change detection.
• Scope is the 12 project-based AppHosts referenced by the test project; file-based AppHost samples (apphost.cs / apphost.mts) aren't referenced and aren't covered.

true

[Copilot]

Pull request overview

Adds an integration test that snapshots the Aspire publish manifest output for each project-based sample AppHost, ensuring publish-manifest changes are surfaced in CI via committed aspire-manifest.json files.

Changes:

• Add ManifestTests to generate publish manifests in-process and compare to committed snapshots (with normalization and cleanup).
• Commit/refresh aspire-manifest.json snapshots alongside sample AppHosts.
• Ignore transient aspire-manifest.g.json output in .gitignore.

Reviewed changes

Copilot reviewed 13 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
tests/SamplesIntegrationTests/ManifestTests.cs	New xUnit theory to generate and snapshot-compare publish manifests (with normalization, config neutralization, and cleanup).
.gitignore	Ignores transient aspire-manifest.g.json generated by the manifest tests.
samples/volume-mount/VolumeMount.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/orleans-voting/OrleansVoting.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/Metrics/MetricsApp.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot (includes neutralized OTLP settings).
samples/health-checks-ui/HealthChecksUI.AppHost/aspire-manifest.json	Refreshes expected manifest snapshot to current publish output.
samples/database-migrations/DatabaseMigrations.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/database-containers/DatabaseContainers.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/custom-resources/CustomResources.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot (includes unsupported-resource error entries).
samples/client-apps-integration/ClientAppsIntegration.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/aspire-with-node/AspireWithNode.AppHost/aspire-manifest.json	Refreshes expected manifest snapshot to current publish output.
samples/aspire-with-javascript/AspireJavaScript.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/aspire-with-azure-functions/ImageGallery.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.
samples/aspire-shop/AspireShop.AppHost/aspire-manifest.json	Adds committed expected publish manifest snapshot.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[IEvangelist]

Good catch — the truncated/invalid JSON was a symptom, not just a bad snapshot. aspire publish was actually failing for this sample: under the current Aspire.Hosting.JavaScript, combining an explicit run script (runScriptName / WithRunScript) with an existing hand-authored Dockerfile is rejected unless the container entrypoint is set explicitly, so the publishing pipeline threw partway through writing the angular resource. The in-process host stops on that failure without faulting RunAsync, so the test wrote the truncated manifest and still passed.

Fixed by setting the nginx entrypoint explicitly on the angular/react/vue apps:

.PublishAsDockerFile(container => container.WithEntrypoint("/docker-entrypoint.sh"));

The manifest now regenerates complete and valid (all five resources). I also hardened ManifestTests to fail when publish produces a missing/truncated/invalid manifest — and to route the AppHost logs to the test output so the underlying publish error is visible — so a broken sample can't silently pass again.