VMR Validation Proposal #15354
VMR Validation Proposal #15354
Conversation
|
|
||
| ### VMR PR/CI builds a selected subset of verticals and scenarios | ||
|
|
||
| On insertion into a VMR, we will run a selected representative subset of scenarios. This representative subset may change over time as the product changes, however, a rough sketch may look like: |
There was a problem hiding this comment.
we will run a selected representative subset of scenarios.
How will these be defined? Or are these simply hand-picked legs from existing list?
There was a problem hiding this comment.
I should have said "How are these defined?" given the Completed status.
There was a problem hiding this comment.
These were hand-picked initially based on what we thought the right matrix is given the changes we are making. An x86, x64, and arm64 leg across various platforms, a few short stack legs, etc.
|
|
||
| We will introduce the ability to trigger optional full VMR insertion validation on PRs. These will run a desired subset of the MSFT/source-only VMR builds and validation. We believe this is a net-net win overall for the product. | ||
|
|
||
| **Scheduling: Can be implemented now.** |
There was a problem hiding this comment.
Does this mean there will be a similar darc-powered VMR sync happening like it happens now in SDK PRs?
Because I don't think the tooling is quite ready (but not far neither).
What happens now in SDK PRs is sort of a "paste" where we take the current SHA1 of the repo in the VMR, the SHA2 of the PR branch and we create patch SHA1_SHA2 in the repo and apply it onto the VMR (plus some patch operations, cloaking..).
But this will differ when we have the flat flow. The forward flow logic does something different based on what the last flow between the repos was and whether there is conflicting content.
The result is that the current way basically inserts/overwrites the repo contents in the VMR, the latter pushes new changes to the VMR but might be based off of an older commit of the target branch when conflicts with the tip prevent to apply the changes on top of it.
Which behaviour do we want for this insertion? I'd say the both can have cases where the VMR has some updates you won't be able to possibly include in your PR build. I'd say the latter is better because it will mimic more what will happen on a subsequent forward flow.
There was a problem hiding this comment.
Yeah I think we want something closer to the forward flow in this case.
There was a problem hiding this comment.
Okay, I will make this an item in the "Prepare tooling for flat flow" epic
Co-authored-by: Michael Simons <[email protected]> Co-authored-by: Přemek Vysoký <[email protected]>
…into vmr-validation-doc
mmitche
requested review from
danmoseley,
artl93,
marcpopMSFT,
jeffschwMSFT and
merriemcgaw
To double check: