CI and Infrastructure

GitHub Actions run our CI pipeline.

Our configuration is found in the standard location for GitHub Actions, ./.github/workflows/build.yml. See this file for detailed job configuration and steps.

Jobs are specified in the pipeline's config. The status and results of jobs are reported as GitHub Checks.

See the GitHub Actions Documentation for more info.

CI Tasks

The CI pipeline performs several tasks when triggered to run. The pipeline is triggered on push or pull request events for the main or release branches (rel/*), and it can also be triggered manually through the Actions tab on GitHub.

Check XAML Styling

A job Xaml-Style-Check is run to enforce XAML styling conventions. It runs on the latest Windows environment and includes steps to install the required .NET SDK, check out the repository, restore necessary tools, and apply XAML Styling using a PowerShell script.

If this step fails for you, run the script ./ApplyXamlStyling.ps1 -Main locally to fix the styling for your XAML, then push to try again.

Build

This job step depends on the Xaml-Style-Check job, and does not run until the XAML Style check passes.

This builds both Uno.UI/WinUI2/UWP and Uno.WinUI/WinUI3/WindowsAppSDK versions of our packages using a matrix strategy.

It is configured to run on a larger windows-latest environment and includes steps for:

• Configuring a page file
• Collecting user-mode dumps if diagnostics are enabled
• Installing the required .NET SDK
• Setting up msbuild
• Enabling target frameworks based on the matrix strategy
• Formatting the date/time for package versions differently depending on whether the build is a release or not
• Packing experiments and pushing packages to our DevOps Artifacts Feed for pull requests
• Running tests, including setup for VSTest and Testspace
• Uploading diagnostic logs and dump files if diagnostics are enabled

Sign and Release

Two jobs, sign and release, handle the signing and releasing of packages.

• The sign job is conditional on the build being from the main or a release branch. It involves downloading the package list and built packages, installing the signing tool, signing the packages, and then pushing the signed packages.

• The release job, which is dependent on the sign job, pushes the signed packages to NuGet.org. It is only triggered for builds from release branches and requires manual approval through the nuget-release-gate environment.

WASM on Linux

A separate job for building WebAssembly (WASM) targets on Linux is also included. This job involves setting up the .NET SDK, checking out the repository, restoring dotnet tools, enabling WASM target frameworks, generating the solution, and installing ninja for WASM native dependencies. Diagnostic logs are uploaded as artifacts.

This step ensures that the Community Toolkit builds and tests successfully under WebAssembly on Linux, which is important for our Live Sample Docs and for using the Community Toolkit in a GitHub Codespace.