ci: add build-samples workflow for Phase 2 Windows-only heads (#510)#514
Conversation
…ityToolkit#510) Adds windows-latest CI coverage for the WinUI3, WPF, and MAUI (Windows TFM) TodoApp heads, plus the todoapp-tutorial ClientApp (WPF) head that Phase 1 (CommunityToolkit#509) explicitly deferred. - New build-samples-todoapp-windows.yml builds TodoApp.WinUI3.csproj (with -p:Platform=x64, required since the project declares x86/x64/ARM64 with no AnyCPU), TodoApp.WPF.csproj, and TodoApp.MAUI.csproj scoped to net10.0-windows10.0.19041.0 only (the maui-windows workload is installed first; Android/iOS heads remain out of scope, tracked in CommunityToolkit#511). - build-samples-todoapp-tutorial.yml gains a second job that builds ClientApp.csproj (WPF) on windows-latest, alongside the existing ServerApp job on ubuntu-latest. - build-samples.yml wires the new todoapp-windows job into the orchestrator and its all-samples-built gate.
'dotnet build' on windows-latest (added in this PR's new build-samples-todoapp-windows.yml job) surfaces NETSDK1198: the project references a 'win-$(Platform).pubxml' publish profile that has never existed in the repo (no Properties/PublishProfiles folder checked in). It's benign scaffold metadata from an incomplete WinUI3 template setup with no effect on 'dotnet build' output, but it's dangling and unused, so remove it rather than suppress the warning.
|
Follow-up fix: the new Assessment: not build-breaking — Fix (052980a): removed the dangling |
…-windows
'dotnet restore' has no --framework option; -f on restore means
--force (a boolean flag), unlike 'dotnet build' where -f/--framework
is a real option. Passing '-f net10.0-windows10.0.19041.0' caused
restore to interpret the TFM string as a second positional project
argument, failing with MSB1008 ("Only one project can be specified").
Scope restore to the single Windows TFM via the MSBuild property
instead.
|
Follow-up fix: the Root cause: Fix (e7c0d42): scope the MAUI restore to the Windows TFM via the MSBuild property directly ( |
|
Follow-up cleanup filed: the successful
None of these fail the build (warnings only) or block this PR. |
* 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>
1 participant
Summary
Closes #510 (Phase 2 of the samples CI rollout, follow-up to #509 / PR #512).
Adds
windows-latestCI coverage for the Windows-only TodoApp build heads that Phase 1 explicitly deferred:samples/todoapp/TodoApp.WinUI3/TodoApp.WinUI3.csprojnet10.0-windows10.0.19041.0samples/todoapp/TodoApp.WPF/TodoApp.WPF.csprojnet10.0-windowssamples/todoapp/TodoApp.MAUI/TodoApp.MAUI.csprojnet10.0-windows10.0.19041.0samples/todoapp-tutorial/ClientApp/ClientApp.csprojnet10.0-windows(WPF)Changes
build-samples-todoapp-windows.yml— awindows-latestjob that builds WinUI3, WPF, and MAUI in sequence:-p:Platform=x64, since the project declares<Platforms>x86;x64;ARM64</Platforms>with noAnyCPU— the CLI's defaultPlatform=AnyCPUis not valid for this project.-f net10.0-windows10.0.19041.0only, after installing themaui-windowsworkload.TodoApp.MAUI.csprojtargetsnet10.0-android;net10.0-ios, with the Windows TFM conditionally appended only when building on Windows — the Android/iOS heads need separate workloads and remain out of scope here (tracked in Add CI workflow to build mobile /samples heads: Android, iOS, Uno (Phase 3 of #509) #511, Phase 3). Usingmaui-windows(rather than the genericmauimeta-workload) avoids pulling in the Android SDK on this runner.build-samples-todoapp-tutorial.yml— added a second job,build-clientapp(windows-latest), buildingClientApp.csproj(WPF). The existingServerAppjob (renamedbuild-serverapp) is unchanged aside from the env var rename (ProjectFile→ServerProjectFile) for symmetry with the newClientProjectFile. Removed the now-resolved comment deferringClientAppto this issue.build-samples.yml— wired the newtodoapp-windowsjob into the orchestrator and theall-samples-builtgate job; updated the stale Phase 2/3 comment to reference only the remaining Phase 3 follow-up (Add CI workflow to build mobile /samples heads: Android, iOS, Uno (Phase 3 of #509) #511).Verification
actionlintpasses on all 3 changed/new workflow files.dotnet restore Datasync.Toolkit.sln && dotnet build Datasync.Toolkit.sln --configuration Release --no-restoresucceeds with 0 errors/warnings (confirms no regression to the core library; the root solution doesn't referencesamples/**).dotnet restore/buildexecution for the four Windows-only heads above. This dev environment is macOS with no .NET workloads installed and no support fornet10.0-windows*TFMs, so these steps can only be exercised once this PR'swindows-latestCI job actually runs. Confirmed themaui-windowsworkload ID is valid viadotnet workload search mauiand cross-checked each project's TFM/Platformsshape by reading the.csprojfiles directly.Related