Add Patina End-to-End Validation Flow [Rebase & FF]

[makubacki]

One main commit and a couple of peripheral commits.

---

Add Patina QEMU validation workflow and actions

Adds a new workflow that will run changes in the patina repository
against the latest code and releases from other Patina repositories.

The main files to support this workflow are:

Workflows:

• .github/workflows/PatinaQemuPrValidation.yml: The workflow file
  that defines the steps to run the validation.
• .github/workflows/PatinaQemuPrValidationPost.yml: A workflow that
  runs after the main validation workflow to post results in a comment
  back to the PR.

Actions:

• .github/actions/setup-patina-qemu-validation: A GitHub Action that
  sets up the environment for running the QEMU validation tests.
• .github/actions/run-patina-qemu-validation: A GitHub Action
  that runs the QEMU validation tests.
• .github/actions/extract-build-errors: A GitHub Action that
  extracts build errors from the QEMU validation logs and formats
  them for posting back to the PR.

---

PatinaQemuPrValidation.yml is expected to be triggered on pull
requests into the patina repository.

A common set of steps are organized in a "Preflight" job. This
generates cache keys for different dependencies and determines that
there is version compatibility to proceed with the rest of the
workflow. This job tries to reduce the likelihood of hitting the
GitHub API rate limit through authenticated requests and caching.

The platform validation portion builds the Q35 and SBSA binaries in
a standalone step instead of in combination with the script invocation
that runs the tests. This allows for clear differentiation between
build and runtime failures. Special parameters were added to the
build_and_run_rust_binary.py script in patina-qemu to support this.

Comments posted back to the patina PR are meant to be as helpful as
possible resulting in some overhead to generate them. The parsing
and heuristic details might need to be tweaked over time.

---

Notes:

• Concurrent runs of the workflow for the same PR are prevent in the
  calling workflow in the patina repository.
• GitHub API requests are made using authenticated requests. Reads
  generally use the default GitHub token while writes use the Patina
  app-derived token. The secrets necessary to derive the app token
  are not available every reads are performed or it would be used for
  everything.
• Special handling is added to work within a container.
• Actual Rust compilation and runs happen in parallel jobs.
• Only one comment is posted by the workflow. It is edited when new
  updates are posted. The coment revision history can be used to see
  the history of updates to the comment.
• The comment format varies between compilation failures and runtime
  failures to provide relevant detail for each when they occur.
• Succeess comments include execution time (exlcuding build time) to
  run QEMU and shutdown.
• Compilation failures include snippets of failures in the logs and
  links to the full log artifacts.
• Runtime failures similarly include snippets of ERROR messages and
  links to the full log artifacts.

Additional Information

Preflight and Parallelization

Preflight checks largely operate on cached data as much as possible. Actual build and platform validation occur in parallel as shown below.

Successful Run

Prints the boot time to shell.

Compilation Failure

Force a compilation failure by changing EFI_PROGRESS_CODE to EFI_PROGRESS_CODE2:

Failure in the workflow:

Compilation failure specific PR comment:

Expanded error details include snippets of failure messages:

Boot Failure

Here SBSA execution fails.

The PR comment has runtime details and shows that only SBSA failed:

---

Other Commits

Update rust-tool-cache cache action version to v5

Updates action version in .github/actions/rust-tool-cache/action.yml
to latest (matching what is used in other files in the repo).

---

Add qemu-constants.yml workflow

Adds constant used for Patina QEMU workflows to patina-devops so they
can be reused in workflows that will build and test patina changes
on QEMU.

[Javagedes]

Do we need to place these workflows here, rather than in Patina? I only ask because this will only ever be used in Patina, and by adding it here rather than patina repo, it adds some unnecessary complexity if we wish to make updates.

[makubacki]

Do we need to place these workflows here, rather than in Patina? I only ask because this will only ever be used in Patina, and by adding it here rather than patina repo, it adds some unnecessary complexity if we wish to make updates.

You're correct but I generally wanted to consolidate workflow and related implementation in this repo because it:

1. Reduces the number of action updates across all repos and makes them consistent
   • Since a single update is made to this repo and small workflows in other repos call into the larger implementation here
2. Reduces the amount of devops overhead in each repo, so the history and code in that repo is more focused on the repo's purpose