microsoft/mu_plus v2025110000.0.4

v2025110000.0.4

Repository: microsoft/mu_plus

Tag: v2025110000.0.4

Published: 2026-04-23T20:05:35Z

Prerelease: no

Release notes:

What's Changed

Skip Mu PR validation for PRs targeting non-default branches @makubacki (#872)

Change Details

Description

Because mu-pr-validation.yml is in the default branch (release/202511) and runs on a workflow_run trigger for the CodeQL workflow where the CodeQL workflow runs for all release branches, the Mu PR Validation workflow will run for all PRs targeting any release branch.

Because mu_tiano_platforms is only compatible with default branches, we want to skip Mu PR Validation targeting those non-default branches.

• [ ] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

Verified for PRs against the default on non-default branch on my fork.

Non-Default Case (Skip)

Default Case (Run)

Integration Instructions

• N/A

MsGraphicsPkg/SwmDialogsLib: Show OSK after dialog rendering completes @makubacki (#866)

Change Details

Description

Moves the ShowKeyboard() call after the canvas Draw() call in the KEYFOCUS handling block of PasswordDialog and SemmUserAuthDialog.

Previously, the on-screen keyboard was displayed before the dialog finished rendering at its shifted position.

By deferring ShowKeyboard() until after Draw() completes, the dialog is fully painted in its final position before the keyboard appears.

• [x] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

1. Go to the "Security -> UEFI password" page 2. In the "Enter password" screen, touch the blank area on the screen 3. Watch the on-screen keyboard load

Integration Instructions

• N/A

mu-pr-validation-pending.yml: Temporarily disable commit status updates @makubacki (#870)

Change Details

Description

The Mu Automation GitHub app requires a permission update to be accepted by a microsoft org admin. Until that happens, disable the calling the GitHub API to update the commit status.

This will still run validation and post PR comments. The pass/fail result just won't be reported in the status check area of the PR until the permission is allowed.

• [ ] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

• N/A

Integration Instructions

• N/A

.github: Add Mu PR Validation workflow @makubacki (#865)

Change Details

Description

Adds workflows to run QEMU-based platform validation on pull requests to mu_plus. This includes:

• mu-pr-validation.yml: The main workflow that performs the actual QEMU validation, including building and booting.

• mu-pr-validation-pending.yml: A workflow that posts an immediate "pending" notification on a pull request when it's pushed, indicating that QEMU validation is waiting for CI to complete. This is broken out to its own workflow to use the pull_request_target trigger (access to secrets on PRs from public forks) while minimizing the amount of code that runs with those elevated permissions.

• mu-pr-validation-post.yml: A workflow that posts the results of the QEMU validation run to the pull request once the validation is complete.

---

Notes

This workflow differs slightly from the Mu Basecore equivalent file in that it is triggered by the CodeQL workflow instead of the CLANGPDB Package CI workflow used there. The reason is that the CLANGPDB Package CI workflow was not added to mu_plus since mu_plus requires Rust code to be built and that workflow doesn't include Rust build support. The CodeQL workflow in mu_plus serves a similar purpose by verifying local package compilation prior to attempting a mu_tiano_platforms build with the changes.

---

• [ ] Impacts functionality?
• [ ] Impacts security?
• [ ] Breaking change?
• [ ] Includes tests?
• [ ] Includes documentation?

How This Was Tested

Ran the workflow under various conditions on my mu_plus fork.

Note that the "boot times" are not precise. They are the total time for the --flashonly step to run including stuart overhead. However, they are not too far off from the boot time and provide the ability to get a relative sense of perf impact.

---

PENDING STATE (when the workflow is waiting for CI to finish)

IN PROGRESS (building / booting QEMU FW with the change)

Granular status updates (see ending text):

SUCCESS

Integration Instructions

• N/A - Only impacts PR validation in this repo

Full Changelog: https://github.com/microsoft/mu_plus/compare/v2025110000.0.3...v2025110000.0.4