Is Ready for Stage labeling redundant?

[Axelcureno]

Kicking off this conversation as a follow-up to improve and expedite our Stage merging process by potentially removing a seemingly redundant step.
If my assumption is correct, only QA can add both the Verified and Ready for stage labels to a PR and there is no precondition to adding the Ready for stage label once a PR is verified (we already have checks to prevent merging PRs without coverage/performance checks, etc).
What we've seen happening is that QA sometimes adds the Verified label but doesn't add the Ready for stage label hence delaying the process of merging.
Is there a scenario where a PR is verified but not eligible for Ready for stage?
Can we remove the "Ready for stage" labeling step given that verified is sufficient for the expected criteria? Or maybe automate the labeling?

[mokimo]

That’s closely in line with https://github.com/orgs/adobecom/discussions/2302 - however with the remark that verified is the redundant label, given that the automation scripts depend on the Ready for Stage label

[3ch023]

Warriors team uses 'verified' label to merge the commerce-related PRs that touch 'conflicting' dependencies files, like /deps/merch-* or /deps/commerce.

The process is below.
'MAS' is the name of our commerce repository.

1. Create a MAS PR
2. Create a Milo branch (no PR at this moment)
3. Obtain 2 MAS PR dev approves
4. PR raised in Milo with /deps generated from branch
5. Obtain 2 Milo PR dev approvals
6. PR in Milo verified by QA → QA puts ‘run-nala’ label if there is none, puts ‘verified’ label on Milo PR and ‘VALIDATE IN MILO" label on MAS PR once verified
7. QA puts the Milo PR to the bottom of the queue
8. When PR is on top of the list, developer merges his MAS PR
9. Developer updates the milo PR with /deps from main
10. QA smoke tests Milo PR and puts ‘Ready for Stage’ when the PR has 2 approvals and all checks have passed

We adopted this process last week because of the increasing risk of developers overwriting the changes from each other. We are open for feedback.
Yesterday discussed it also with @narcis-radu as it is confusing for code reviewers.
However, as of now, I can't see a simpler way to go.

[mokimo]

Why the dependency on milo to merge MAS PRs? I would imagine the process to be in line with how any npm package would work. Aka, there is no dependency to libraries that consume the package.

1. Library (MAS) bumps their version, everything is tested, approved, merged, etc. at MAS level. Let's call it MAS-DEP V1.0
2. PR raised to milo with MAS-DEP V1.0

Now let's say MAS-DEP V1.0 encounters an error on milo

3. Milo PR changes are requested // open a ticket for MAS changes as MAS-DEP V1.0 has bug X
4. MAS bumps their version fixing bug X, everything is tested, approved, merged, etc. at MAS level. Let's call it MAS-DEP V1.1 after that is done
5. Milo PR updated with MAS-DEP v1.1, changes are tested, approved, merged.

[narcis-radu]

I had the same question and from what I understand some features cannot be tested without Milo changes. However, that could be done with a feature branch + custom MAS library path (e.g. test--milo--narcis-radu.hlx.page?maslib=my-feature-maslib--mas--narcis-radu).

[3ch023]

Before the process above we had something like this:

1. Create a MAS PR
2. Create a Milo branch (no PR at this moment)
3. Obtain 2 MAS PR dev approves
4. QA tests on Milo branch, adds ‘VALIDATED IN MILO" label
5. Dev merges MAS PR in main
6. Dev raise PR in Milo with /deps generated from main branch
7. Obtain 2 Milo PR dev approvals
8. QA puts ‘run-nala’ label if there is none, re-validates, puts 'Ready for Stage'

But one of the issues we are encountering is that MAS repo PRs are merged and merged, while Milo PRs take time to review and merge, so at some moment we have 3 PRs in MAS main that are not yet merged in MILO, therefore any change to MAS repository is blocked.

[mokimo]

But one of the issues we are encountering is that MAS repo PRs are merged and merged, while Milo PRs take time to review and merge, so at some moment we have 3 PRs in MAS main that are not yet merged in MILO, therefore any change to MAS repository is blocked.

Ah you wouldn't want to include recent changes and just fix the bug for a specific MAS-Version, correct? If it's always "main" and "release-candidate" you could have 2 running branches, the downside would be a potential bug fix discovered after milo testing would need to be merged to main and the release-candidate branch.

[npeltier]

also https://github.com/orgs/adobecom/discussions/2378