You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Surfaced during the #499 / #508 investigation (and noted as a gap in #507): /samples has no CI coverage at all today. None of the existing workflows (build-library.yml, build-docs.yml, build-template.yml) touch the samples/** path, so a PR can introduce a broken sample (bad package bump, breaking API change, stale TargetFramework, etc.) and nothing will catch it until someone manually opens the solution or a security scan flags a transitive dependency. That's effectively what happened with #492/#498/#499/#506 — none of those regressions were caught by CI.
This issue asks for a new workflow that builds every sample solution whenever a PR touches samples/**, mirroring the path-filtered pull_request trigger pattern already used by build-library.yml and build-template.yml.
Uno.Sdk (pinned via global.json, currently 5.4.5) + android/ios/maui/wasm-tools workloads across runners; note: the desktop head currently has a pre-existing NU1605 (Uno.WinUI version mismatch) per #506 that will need resolving before this head builds cleanly in CI
ubuntu-latest, likely needs wasm-tools workload for the client head
Suggested approach
Given how heterogeneous the runner/workload requirements are across this list, a single dotnet build **/*.sln step won't work. Suggest a phased rollout instead of trying to cover everything in one PR:
Phase 1 — low-hanging fruit: add a build-samples.yml workflow (triggered on pull_request/push to main with paths: ['samples/**', '.github/workflows/build-samples.yml']) that builds the plain net10.0 samples with no extra workloads on ubuntu-latest: datasync-server, datasync-server-cosmosdb-singlecontainer, todoapp-tutorial, todoapp-mvc, todoapp-blazor-wasm, and the Avalonia shared+Desktop projects (TodoApp.Avalonia.csproj + TodoApp.Avalonia.Desktop.csproj) specifically (not the full .sln, to avoid pulling in the Android/iOS heads before workloads are set up).
Phase 2 — Windows-only heads: add a windows-latest job for TodoApp.WPF, TodoApp.WinUI3, and the MAUI Windows TFM.
Phase 3 — mobile heads: add android/ios/maui workload installation steps and build the Android/iOS heads for Avalonia, Uno, and MAUI. iOS builds will need a macOS runner. This phase should start with Avalonia (the pattern is simplest — 2 mobile heads, no Uno.Sdk complications) before attempting Uno, since Uno's desktop head is currently blocked by the unrelated NU1605 from Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506.
Consider continue-on-error: true (or excluding entirely) for any sample/head known to have a pre-existing, unrelated build break (e.g., Uno desktop per Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506) until that's fixed, so the new workflow doesn't start life red for reasons outside a given PR's control.
Should be build-only (dotnet restore + dotnet build), not run/test — most of these are UI apps without a practical headless test story today. A follow-up could explore headless Avalonia UI tests, but that's out of scope here.
Summary
Surfaced during the #499 / #508 investigation (and noted as a gap in #507):
/sampleshas no CI coverage at all today. None of the existing workflows (build-library.yml,build-docs.yml,build-template.yml) touch thesamples/**path, so a PR can introduce a broken sample (bad package bump, breaking API change, staleTargetFramework, etc.) and nothing will catch it until someone manually opens the solution or a security scan flags a transitive dependency. That's effectively what happened with #492/#498/#499/#506 — none of those regressions were caught by CI.This issue asks for a new workflow that builds every sample solution whenever a PR touches
samples/**, mirroring the path-filteredpull_requesttrigger pattern already used bybuild-library.ymlandbuild-template.yml.Inventory of what needs building
samples/todoapp/TodoApp.Avalonia/TodoApp.Avalonia.slnnet10.0(shared+desktop),net10.0-android,net10.0-iosubuntu-latestfor shared+desktop;androidworkload for Android head;iosworkload + macOS/Xcode for iOS headsamples/todoapp/TodoApp.Uno/TodoApp.Uno.slnnet10.0-android;net10.0-ios;net10.0-maccatalyst;net10.0-windows10.0.26100;net10.0-browserwasm;net10.0-desktopglobal.json, currently 5.4.5) +android/ios/maui/wasm-toolsworkloads across runners; note: the desktop head currently has a pre-existingNU1605(Uno.WinUIversion mismatch) per #506 that will need resolving before this head builds cleanly in CIsamples/todoapp/Samples.TodoApp.slnnet10.0-windows10.0.19041.0(WinUI3),net10.0-windows(WPF),net10.0-android;net10.0-ios;net10.0-maccatalyst;net10.0-windows10.0.26100;net10.0-browserwasm;net10.0-desktop(MAUI)windows-latestrequired for WinUI3/WPF and the MAUI Windows TFM;maui/android/iosworkloads for the restsamples/datasync-server/Sample.Datasync.Server.slnnet10.0ubuntu-latest, no extra workloadssamples/datasync-server-cosmosdb-singlecontainer/Datasync.Server.CosmosDb.SingleContainer.slnnet10.0ubuntu-latest, no extra workloads (theinfra/Bicep/Terraform, if present, is out of scope for adotnet buildjob)samples/todoapp-tutorial/todoapp.slnnet10.0ubuntu-latest, no extra workloadssamples/todoapp-mvc/part5.slnnet10.0ubuntu-latest, no extra workloadssamples/todoapp-blazor-wasm/TodoApp.BlazorWasm.slnnet10.0ubuntu-latest, likely needswasm-toolsworkload for the client headSuggested approach
Given how heterogeneous the runner/workload requirements are across this list, a single
dotnet build **/*.slnstep won't work. Suggest a phased rollout instead of trying to cover everything in one PR:build-samples.ymlworkflow (triggered onpull_request/pushtomainwithpaths: ['samples/**', '.github/workflows/build-samples.yml']) that builds the plainnet10.0samples with no extra workloads onubuntu-latest:datasync-server,datasync-server-cosmosdb-singlecontainer,todoapp-tutorial,todoapp-mvc,todoapp-blazor-wasm, and the Avalonia shared+Desktop projects (TodoApp.Avalonia.csproj+TodoApp.Avalonia.Desktop.csproj) specifically (not the full.sln, to avoid pulling in the Android/iOS heads before workloads are set up).windows-latestjob forTodoApp.WPF,TodoApp.WinUI3, and the MAUI Windows TFM.android/ios/mauiworkload installation steps and build the Android/iOS heads for Avalonia, Uno, and MAUI. iOS builds will need a macOS runner. This phase should start with Avalonia (the pattern is simplest — 2 mobile heads, no Uno.Sdk complications) before attempting Uno, since Uno's desktop head is currently blocked by the unrelatedNU1605from Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506.continue-on-error: true(or excluding entirely) for any sample/head known to have a pre-existing, unrelated build break (e.g., Uno desktop per Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506) until that's fixed, so the new workflow doesn't start life red for reasons outside a given PR's control.Should be build-only (
dotnet restore+dotnet build), not run/test — most of these are UI apps without a practical headless test story today. A follow-up could explore headless Avalonia UI tests, but that's out of scope here.Related
Tmds.DBus.ProtocolNU1903 fix, merged with no CI verification beyond manualdotnet build.Tmds.DBusNU1903 investigation; blocked by the pre-existing Uno.WinUINU1605that this new workflow would also need to contend with.