ci: add build-samples workflow for Phase 1 low-workload samples#512
Merged
Conversation
…unityToolkit#509) Adds CI coverage for /samples, which previously had none. Introduces a build-samples.yml orchestrator that calls one reusable per-sample workflow per build target, plus an all-samples-built gate job so branch protection only needs a single required check. Phase 1 scope covers the plain net10.0 samples that build on ubuntu-latest with no extra workloads: - datasync-server - datasync-server-cosmosdb-singlecontainer - todoapp-mvc - todoapp-blazor-wasm - todoapp-tutorial (ServerApp only; ClientApp is WPF/net10.0-windows, tracked in CommunityToolkit#510) - Avalonia shared + Desktop projects (not the full .sln, to exclude the Android/iOS heads, tracked in CommunityToolkit#511) Windows-only heads (WPF, WinUI3, MAUI-Windows, tutorial ClientApp) and mobile heads (Android, iOS, Uno) are filed as separate follow-up issues (CommunityToolkit#510, CommunityToolkit#511) per the phased rollout the issue recommended.
This was referenced Jul 7, 2026
adrianhall
added a commit
that referenced
this pull request
Jul 7, 2026
* ci: add build-samples workflow for Phase 3 mobile heads (#511) Adds CI coverage for the Android/iOS/Uno mobile build heads deferred from Phase 1 (#509/#512) and Phase 2 (#510/#514): - build-samples-todoapp-avalonia.yml: add android (ubuntu-latest) and ios (macos-latest) jobs for TodoApp.Avalonia.Android/.iOS. - build-samples-todoapp-maui.yml (new): android and ios jobs for TodoApp.MAUI, each scoped to a single TargetFramework via -p:TargetFramework / -f (the Windows head remains in build-samples-todoapp-windows.yml from Phase 2). - build-samples-todoapp-uno.yml (new): one job per TodoApp.Uno head (android, ios+maccatalyst, windows, browserwasm, desktop), each restoring/building the single multi-TFM project scoped to one TargetFramework at a time. - build-samples.yml: wire the two new sample workflows into the orchestrator and the all-samples-built gate. The desktop head is intentionally NOT marked continue-on-error here. #506's NU1903 (Tmds.DBus) finding is a NuGet audit warning only and this repo does not configure NuGet audit to fail builds. #506 also reports a NU1605 hit while investigating that warning, but that has not been confirmed to reproduce today or to be desktop-specific (CommunityToolkit.WinUI.Behaviors is referenced unconditionally in TodoApp.Uno.csproj), so all Uno heads are left as normal, blocking jobs pending real CI signal. actionlint passes on all 5 changed/new workflow files. Verified 'dotnet restore/build Datasync.Toolkit.sln --configuration Release' still succeeds with 0 warnings/errors (no regression to the core library). The mobile/Uno workload installs and builds themselves cannot be verified locally (no Android SDK, no full Xcode, no Windows) and will be confirmed once CI runs on this branch. * fix: align Info.plist MinimumOSVersion with SupportedOSPlatformVersion for TodoApp.Avalonia.iOS CI (added in #511) surfaced a pre-existing mismatch: Info.plist declared MinimumOSVersion 13.0 while TodoApp.Avalonia.iOS.csproj declares SupportedOSPlatformVersion 15.0, which the iOS build task hard-fails on ('The MinimumOSVersion value in the Info.plist (13.0) does not match the SupportedOSPlatformVersion value (15.0) in the project file'). Bump Info.plist's MinimumOSVersion to 15.0 to match the csproj, which is treated as the source of truth here. Unrelated to this fix: the same CI run also surfaced a pre-existing CS8604 nullable-reference warning in the shared LoggingHandler.cs. It does not fail the build (the run reported 1 warning, 1 error - only the Info.plist mismatch was the error) and is left untouched to keep this change scoped to the actual build failure. * ci: disable todoapp-uno job pending #506 CI confirmed the NU1605 (Uno.WinUI 5.5.87 vs 5.4.22, driven by CommunityToolkit.WinUI.Behaviors' floor vs. the Uno.Sdk pin in global.json) is not desktop-specific as originally suspected in #511 - it fails restore for every TodoApp.Uno head (confirmed via the android-head CI log and locally reproduced on net10.0-desktop, no workload required), since CommunityToolkit.WinUI.Behaviors is referenced unconditionally in TodoApp.Uno.csproj. Comment out the todoapp-uno job in build-samples.yml's orchestrator (and drop it from all-samples-built's needs) rather than trying to patch around it here. build-samples-todoapp-uno.yml itself is left fully intact (one job per head, TFM-scoped restore/build) and just needs to be wired back in once #506 lands a fix and TodoApp.Uno.csproj restores cleanly. Posted the concrete reproduction details to #506 so the fix for that issue also covers re-enabling this CI job. --------- Co-authored-by: ahall <ahall@cloudflare.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes part of #509 (Phase 1 of the samples CI rollout).
/samplespreviously had zero CI coverage. This adds abuild-samples.ymlworkflow that builds the plainnet10.0samples with no extra workloads onubuntu-latest, triggered on any PR/push tomaintouchingsamples/**.What's included (Phase 1 — no extra workloads, ubuntu-latest)
datasync-server(Sample.Datasync.Server.sln)datasync-server-cosmosdb-singlecontainer(Datasync.Server.CosmosDb.SingleContainer.sln)todoapp-mvc(part5.sln)todoapp-blazor-wasm(TodoApp.BlazorWasm.sln)todoapp-tutorial—ServerApp.csprojonlyTodoApp.Avalonia.csproj) + Desktop (TodoApp.Avalonia.Desktop.csproj) projects directly, not the full.slnDesign
build-samples-<name>.yml,on: workflow_call), each doingcheckout→setup-dotnet(10.0.x) →dotnet restore→dotnet build --configuration Release.build-samples.yml, owns thepull_request/push/workflow_dispatchtriggers and path filter (samples/**,.github/workflows/build-samples*.yml), and calls each per-sample workflow as a job.all-samples-builtgate job aggregates the results so branch protection only needs one required check as more samples are added over time.Findings during implementation
While verifying the issue's inventory table against the actual sample projects, I found two things that don't fit a
ubuntu-latest/no-workload Phase 1 build and filed them as separate follow-ups so they can be picked up independently:TodoApp.WPF,TodoApp.WinUI3, the MAUI Windows TFM, andtodoapp-tutorial/ClientApp— which turned out to be a WPF app (net10.0-windows), not plainnet10.0as originally listed in Add CI workflow to build all /samples projects on PR #509's table. It isn't built by this PR's workflow.Verification
actionlintpasses on all 7 new workflow files.dotnet restore+dotnet build --configuration Releasefor each of the 6 build targets covered by this PR — all succeed with 0 errors (Blazor WASM Client builds fine without thewasm-toolsworkload, contrary to the issue's speculation that it might be needed).dotnet restore && dotnet build --configuration Releaseat the repo root to confirm no regressions to the main library/test build (0 errors). Did not run the fulldotnet testsuite — this PR touches only.github/workflows/, and the local environment lacks Docker for the TestContainers-based integration tests (a pre-existing, unrelated environment limitation noted in the README).