CI: Use mu_devops workflows and simplify yaml

[Maheer Aeron (maheeraeron)]

Aims to make this repo's CI look closer to other repos from project mu, using workflows from mu_devops where appropriate.

[Maheer Aeron (maheeraeron)]

need to find out how to get this

[Maheer Aeron (maheeraeron)]

testing to see if it works without...

[Mike Ebersol (mebersol)]

[Copilot] Overall this is a good direction — SHA-pinning the third-party actions, fail-fast: false, if-no-files-found: error, and the log-upload step are all real improvements, and adding -legacy-${{ matrix.c-core }} to the artifact name fixes a latent duplicate-artifact-name collision in the old workflow.

Leaving four comments: one blocking (the fork/secrets issue on openvmm-test-x64, which also gates release), and three smaller ones around consistency and discoverability.

[Mike Ebersol (mebersol)]

[Copilot] This job will fail for every fork PR, and it gates release.

openvmm-test.yml declares OPENVMM_ARTIFACT_TOKEN as required: true, and this passes secrets: inherit. Secrets are not available to pull_request runs from forks — including this PR, which comes from maheeraeron/mu_msvm. Every external contributor's PR will show a red required check they have no way to fix.

Suggest gating the job so it only runs when secrets are actually available:

openvmm-test-x64:
  name: OpenVMM Test X64
  needs: build
  if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository
  uses: ./.github/workflows/openvmm-test.yml
  secrets:
    OPENVMM_ARTIFACT_TOKEN: ${{ secrets.OPENVMM_ARTIFACT_TOKEN }}

Two things bundled in there: the if: guard, and explicit secret passing instead of secrets: inherit (least privilege — the called workflow only needs this one).

Also, can you confirm OPENVMM_ARTIFACT_TOKEN is actually provisioned on microsoft/mu_msvm? If it isn't yet, this job fails on main too.

[Mike Ebersol (mebersol)]

[Copilot] GetRequiredSubmodules() and GetPackagesPath() now disagree: Common/PATINA_EDK2 is listed here but the package path just below still returns (".", "MU_BASECORE", "Common/MU", "Feature/DEBUGGER"). MsvmPkg/PlatformBuild.py lists it in both, so CI and platform builds see different package paths.

Either add it to GetPackagesPath() for consistency, or add a one-line comment explaining why the CI build doesn't need it on the path.

Separately — the submodule list is now duplicated verbatim in .pytool/CISettings.py and MsvmPkg/PlatformBuild.py. That's a drift hazard (this PR exists partly because the two drifted). Worth pulling into a shared constant that both import.

[Mike Ebersol (mebersol)]

[Copilot] The guard itself is good, but 6 is an unexplained magic number and the failure message doesn't tell a future maintainer where it comes from.

It's derived from the build matrix: 2 targets x (X64/CLANGPDB legacy TRUE + X64/CLANGPDB legacy FALSE + X64/VS2022 legacy TRUE) = 6. That's non-obvious, and the count silently changes on any intentional matrix edit — e.g. retiring the legacy C core drops it to 4 and turns this red with an error that looks like an artifact-upload failure rather than "you changed the matrix."

At minimum add a comment:

# 2 targets x 3 X64 toolchain/legacy combos (CLANGPDB TRUE+FALSE, VS2022 TRUE).
# Keep in sync with the build matrix in platform-ci.yml.
if [[ "${#firmware_files[@]}" -ne 6 ]]; then

Better still, derive it from the matrix rather than hardcoding.

[Mike Ebersol (mebersol)]

[Copilot] The explanatory comment that lived on the old BASE_VERSION env got dropped in the move:

env:
  # Bump this when releasing a new major/minor version. The patch number
  # auto-increments from the latest existing GitHub release with this prefix.
  BASE_VERSION: "26.0"

This is the one place a maintainer will look when cutting a new minor version, and without the comment the auto-increment/reset semantics aren't discoverable — you'd have to go read the jq expression in release.yml to work out what happens to the patch number. Please carry it over:

    with:
      # Bump this when releasing a new major/minor version. The patch number
      # auto-increments from the latest existing GitHub release with this prefix.
      base-version: "26.0"