OvmfPkg: Pass command-line args to PR Eval

[makubacki]

Description

Allow PR eval to operate with the same input variable values as the build command would.

Because BLD_*_SMM_REQUIRE and BLD_*_STANDALONE_MM_ENABLE were not being passed to PR Eval, bbee92c was merged and broke the mainline because the MM build was not run during the PR gate.

• Breaking change?
• Impacts security?
• Includes tests?

How This Was Tested

Local PR eval run before and after the change. After, PR eval detects the package needs to be built:

Integration Instructions

N/A

[leiflindholm]

Presumably this PR can't pass CI either, so feel free to push manually.

[Javagedes]

Per offline conversation, but for tracking purposes here - please ignore both - and -- args and also handle when the passed in variable is BLD_<target>_ (such as BLD_RELEASE_, not just BLD_*_

[makubacki]

Per offline conversation, but for tracking purposes here - please ignore both - and -- args and also handle when the passed in variable is BLD_<target>_ (such as BLD_RELEASE_, not just BLD_*_

Updated

[makubacki]

There is an internal edk2-pytool-library change I'd like to follow up on further before this PR is merged. tianocore/edk2-pytool-library#750.

[leiflindholm]

There is an internal edk2-pytool-library change I'd like to follow up on further before this PR is merged. tianocore/edk2-pytool-library#750.

OK, but given all merging is blocked until this goes in, could we fast-track that?

[makubacki]

There is an internal edk2-pytool-library change I'd like to follow up on further before this PR is merged. tianocore/edk2-pytool-library#750.

OK, but given all merging is blocked until this goes in, could we fast-track that?

This PR is to help more accurately detect changes that should trigger the OvmfPkg build in pull request checks in the future (future being asap), but didn't bbee92c ultimately break mainline and needs to be reverted (if there's not a better resolution)?

[leiflindholm]

This PR is to help more accurately detect changes that should trigger the OvmfPkg build in pull request checks in the future (future being asap), but didn't bbee92c ultimately break mainline and needs to be reverted (if there's not a better resolution)?

Ah, I wasn't sure on cause and effect. If so, yes. I'll submit one. But then someone with repo write permissions will need to manually push that revert.

[leiflindholm]

Raised #11225.

[leiflindholm]

Ah, I wasn't sure on cause and effect. If so, yes. I'll submit one. But then someone with repo write permissions will need to manually push that revert.

And of course they don't because the revert PR passes CI. I've set the push label on #11225 and it is now merged.

So the only race condition for this PR is we want it merged before the next attempt at #11210 gets its push label set.

[makubacki]

Ah, I wasn't sure on cause and effect. If so, yes. I'll submit one. But then someone with repo write permissions will need to manually push that revert.

And of course they don't because the revert PR passes CI. I've set the push label on #11225 and it is now merged.

So the only race condition for this PR is we want it merged before the next attempt at #11210 gets its push label set.

Sounds good. We're prioritizing concluding the discussion for this PR.

[YangGangUEFI]

It seems that #10975 also has a similar problem?

[leiflindholm]

It seems that #10975 also has a similar problem?

Yeah :(
Thanks for raising #11229