CI/CD - build pipeline - Pt2

[vicocz]

• PR check - validation build do not produce signed arrtifacts
• new release workflows for the default branch and created releases

[Copilot]

Pull request overview

This PR continues the CI/CD pipeline work by pinning the .NET SDK via global.json, introducing a reusable MAUI setup composite action, and splitting validation (PR) workflows from release-capable workflows for Android/iOS/WinUI.

Changes:

• Added global.json to pin the SDK version used by GitHub Actions.
• Introduced .github/actions/setup-maui composite action and updated workflows to use it.
• Added new *-release.yml workflows and adjusted existing workflows to focus on PR validation.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
global.json	Pins the .NET SDK version used by CI.
.github/actions/setup-maui/action.yml	New composite action to set up .NET/MAUI and expose TFM/app-version outputs.
.github/workflows/build-core.yml	Switches to the composite action for SDK setup (no workload install).
.github/workflows/build-android.yml	PR validation build updated to use composite action outputs for TFM.
.github/workflows/build-android-release.yml	New release-capable Android workflow (push/release/workflow_dispatch).
.github/workflows/build-ios.yml	PR validation build updated to use composite action outputs for TFM.
.github/workflows/build-ios-release.yml	New release-capable iOS workflow including signing/TestFlight upload.
.github/workflows/build-windows.yml	PR validation WinUI build updated to use composite action.
.github/workflows/build-windows-release.yml	New release-capable WinUI workflow including signing and release asset upload.

Suppressed comments (2)

.github/actions/setup-maui/action.yml:52

• sed parsing of XML is brittle and assumes sed is available in the runner's bash environment. Since this action runs on Windows/macOS/Linux, it’s safer to parse Directory.Build.props with a tool that’s present everywhere (e.g. Python) and to fail fast if the version can’t be found.

    - id: app-version
      name: Get App Version from Build Properties
      shell: bash
      run: echo "version=$(sed -n 's|.*<ApplicationDisplayVersion>\(.*\)</ApplicationDisplayVersion>.*|\1|p' Directory.Build.props)" >> "$GITHUB_OUTPUT"

.github/workflows/build-android-release.yml:75

• Same quoting issue in the AAB publish step: AndroidSigning*Pass values should be quoted to avoid failures when secrets contain special characters.

        -p:ApplicationVersion="${{ github.run_number }}"
        -p:AndroidSigningKeyPass=${{secrets.KEYSTORE_PASSWORD}}
        -p:AndroidSigningStorePass=${{secrets.KEYSTORE_PASSWORD}}
        -p:AndroidPackageFormat=aab

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (6)

.github/workflows/build-android-release.yml:78

• In the AAB publish step, the keystore password MSBuild properties are not quoted. If the secret contains characters that the shell treats specially (spaces, !, $, etc.), the command can break or the value can be truncated. Quote these values for consistency with the APK step above.

        -f ${{ steps.setup-maui.outputs.target-framework }}
        --no-restore
        -p:ApplicationVersion="${{ github.run_number }}"
        -p:AndroidSigningKeyPass=${{secrets.KEYSTORE_PASSWORD}}
        -p:AndroidSigningStorePass=${{secrets.KEYSTORE_PASSWORD}}
        -p:AndroidPackageFormat=aab

.github/workflows/build-ios-release.yml:32

• This workflow runs on release.published, but checkout doesn’t specify the release tag ref. On release events, actions/checkout defaults to the repository’s default branch, which can produce artifacts that don’t match the tag being released. Explicitly checkout github.ref so release builds are reproducible and correspond to the published tag.

    steps:
    - uses: actions/checkout@v6
    - name: Setup MAUI

.github/workflows/build-android-release.yml:32

• This workflow runs on release.published, but checkout doesn’t specify the release tag ref. On release events, actions/checkout defaults to the repository’s default branch, which can produce artifacts that don’t match the tag being released. Explicitly checkout github.ref so release builds are reproducible and correspond to the published tag.

This issue also appears on line 73 of the same file.

    - uses: actions/checkout@v6
    - name: Setup MAUI

.github/actions/setup-maui/action.yml:52

• This composite action will attempt to install a workload ID of maui- when install-workload is left at its default (true) but neither platform nor workload-id is provided. That will fail and makes the action unsafe to invoke with defaults; add an explicit validation/early-exit when the computed workload id would be empty.

        WORKLOAD_ID="${{ inputs.workload-id }}"
        if [ -z "$WORKLOAD_ID" ]; then
          WORKLOAD_ID="maui-${{ inputs.platform }}"
        fi
        dotnet workload install "$WORKLOAD_ID"

.github/workflows/build-windows-release.yml:32

• This workflow runs on release.published, but checkout doesn’t specify the release tag ref. On release events, actions/checkout defaults to the repository’s default branch, which can produce artifacts that don’t match the tag being released. Explicitly checkout github.ref so release builds are reproducible and correspond to the published tag.

    steps:
    - uses: actions/checkout@v6
    - name: Setup MAUI

global.json:5

• Using rollForward: latestFeature makes the SDK selection non-deterministic over time (CI can silently start using a newer feature-band SDK than the pinned version). If the goal is reproducible builds, consider using the default roll-forward behavior (or latestPatch) instead; if the goal is to float to newer feature bands, it would help to document that intent.

  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestFeature"
  }

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Suppressed comments (6)

.github/workflows/build-android-release.yml:13

• The push.paths filter doesn't include .github/actions/** or global.json, but this workflow depends on the composite actions and pinned SDK. Merges that only change those files won't run this release build on the default/release branches, so pipeline breakages may not be detected until a later unrelated commit.

    paths:
      - '.github/**/*android.yml'
      - '*.props'
      - '*.slnx'
      - 'BrickController2/BrickController2/**'

.github/workflows/build-ios-release.yml:13

• The push.paths filter doesn't include .github/actions/** or global.json, but this workflow depends on the composite actions and pinned SDK. Merges that only change those files won't run this release build on the default/release branches, so pipeline breakages may not be detected until a later unrelated commit.

    paths:
      - '.github/**/*ios.yml'
      - '*.props'
      - '*.slnx'
      - 'BrickController2/BrickController2/**'

.github/workflows/build-windows-release.yml:13

• The push.paths filter doesn't include .github/actions/** or global.json, but this workflow depends on the composite actions and pinned SDK. Merges that only change those files won't run this release build on the default/release branches, so pipeline breakages may not be detected until a later unrelated commit.

    paths:
      - '.github/**/*windows.yml'
      - '*.props'
      - '*.slnx'
      - 'BrickController2/BrickController2/**'

.github/workflows/build-android.yml:21

• This workflow now depends on .github/actions/setup-maui and global.json (via the setup action), but the existing pull_request.paths filter doesn't include those files. A PR that only updates the composite action or the pinned SDK won't trigger this validation build, so CI can miss breaking pipeline changes.

  contents: read

env:
  PROJECT_FOLDER: "BrickController2/BrickController2.Android"

.github/workflows/build-ios.yml:20

• This workflow now depends on .github/actions/setup-maui and global.json (via the setup action), but the existing pull_request.paths filter doesn't include those files. A PR that only updates the composite action or the pinned SDK won't trigger this validation build, so CI can miss breaking pipeline changes.

permissions:
  contents: read

env:
  PROJECT_FOLDER: "BrickController2/BrickController2.iOS"

.github/workflows/build-windows.yml:20

• This workflow now depends on .github/actions/setup-maui and global.json (via the setup action), but the existing pull_request.paths filter doesn't include those files. A PR that only updates the composite action or the pinned SDK won't trigger this validation build, so CI can miss breaking pipeline changes.

permissions:
  contents: read

env:
  PROJECT_FOLDER: "BrickController2/BrickController2.WinUI"

[vicocz]

Obviously it works.