Skip to content

Add GitHub Actions build validation #37

Description

@SamratB8

Summary

Create a GitHub Actions workflow that restores, builds, and tests the WinDroid Runtime solution for pushes and pull requests.

The workflow should use a Windows runner because the solution contains a WinUI 3 application.

This workflow is intended to validate contributions. It should not publish releases or deployment artifacts.

Background

Automated build validation will help contributors identify:

  • Compilation failures
  • Missing project references
  • Dependency-restore problems
  • Debug and Release differences
  • Unit-test failures
  • New warnings where warnings are treated as errors

The repository already provides local build commands. The workflow should follow the same build expectations.

Workflow Triggers

Run the workflow for:

pull_request:
push:

Push triggers may be limited to important branches such as:

main
dev

Use the actual development branch names present in the repository.

Runner Requirements

Use:

runs-on: windows-latest

A Windows runner is required for WinUI and Windows App SDK build compatibility.

Build Requirements

The workflow should:

  1. Check out the repository
  2. Set up the required .NET SDK
  3. Restore the solution
  4. Build Debug configuration
  5. Build Release configuration
  6. Run unit tests
  7. Fail when any required step fails

Use the repository solution:

WinDroid.Runtime.slnx

Suggested Commands

dotnet restore .\WinDroid.Runtime.slnx

dotnet build .\WinDroid.Runtime.slnx `
  --configuration Debug `
  --no-restore

dotnet build .\WinDroid.Runtime.slnx `
  --configuration Release `
  --no-restore

dotnet test .\WinDroid.Runtime.slnx `
  --configuration Release `
  --no-build

Commands may be adjusted if WinUI project behavior requires a more appropriate solution-level test command.

SDK Requirements

The workflow should install the SDK version expected by the repository.

If both .NET 8 targeting and a newer SDK are involved:

  • Document the reason clearly
  • Avoid unnecessary SDK installations
  • Keep the workflow consistent with local build documentation

Permissions

Use minimum workflow permissions.

For a build-only workflow, prefer:

permissions:
  contents: read

Do not grant write permissions unless a future workflow specifically needs them.

Concurrency

Add concurrency control where practical so outdated runs for the same pull request can be cancelled.

concurrency:
  group: build-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Tasks

  • Create .github/workflows/build.yml
  • Add checkout step
  • Configure .NET SDK
  • Restore the solution
  • Build Debug configuration
  • Build Release configuration
  • Run tests
  • Add minimum permissions
  • Add concurrency control
  • Confirm workflow works for pull requests
  • Confirm workflow works for selected push branches
  • Document any runner-specific requirements

Out of Scope

This issue does not need to:

  • Publish MSIX packages
  • Create GitHub releases
  • Sign binaries
  • Upload installers
  • Deploy applications
  • Run Android devices or emulators
  • Install ADB
  • Run hardware-dependent integration tests
  • Upload code-coverage reports
  • Add release versioning

Acceptance Criteria

  • A build workflow exists under .github/workflows/.
  • The workflow runs on pull requests.
  • The workflow runs on configured push branches.
  • The workflow uses a Windows runner.
  • The solution restores successfully.
  • Debug configuration is built.
  • Release configuration is built.
  • Unit tests run automatically.
  • A build or test failure causes the workflow to fail.
  • Workflow permissions are limited to what is required.
  • Overlapping outdated runs are cancelled where configured.
  • No release or deployment artifacts are published.
  • The workflow file is valid YAML.
  • The workflow completes successfully on the current repository state.

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildBuild settings, SDK compatibility, dependency restore, and compilation fixes.ciAutomated checks, validation workflows, and pull request build verification.good first issueGood for newcomersphase-1Work planned for the first development phase and initial usable project foundation.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Status
    Ready

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions