feat: github action to check if PR has requested labels before being merged

[gauthierpetetin]

Description

The purpose of this new Github action is to check if PRs have the requested labels before they get merged:

• A team label, i.e. a label starting with team- string (or external-contributor label)
• A QA label, i.e. either QA Passed or No QA Needed/E2E Only or Spot Check on the Release Build?

Furthermore, it forbids merging PRs with the following labels: needs-qa, QA'd but questions, issues-found, need-ux-ds-review, blocked, stale, DO-NOT-MERGE. A consequence is that we can get rid of this github action.

Screenshots/Recordings

Recording for missing team label: https://recordit.co/U38NvBpIIj
Recording for missing QA label: https://recordit.co/jowmkvMkCh

Issue

Progresses https://github.com/MetaMask/mobile-planning/issues/1122

Checklist

• There is a related GitHub issue
• Tests are included if applicable
• Any added code is fully documented

Other

• Same PR for Extension

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[cortisiko]

🌮 🌮 🌮

[gauthierpetetin]

Hi @cortisiko and @sethkfman ,
I'm not sure how to proceed with this PR, as @sethkfman mentioned last Friday, that enforcing the addition of a QA label on every PR might introduce a habit where contributors rely on Core Mobile QA team when contributing to Mobile code base, while we want to progressively get away from this.
@cortisiko what do you think?
Does it make sense if I update this PR such that it:

• Forces the addition of a team label, i.e. a label starting with team- string (or external-contributor label)
• Forces the addition of QA label, i.e. either QA Passed or No QA Needed/E2E Only or Spot Check on the Release Build
• Forbids PR to be merged if they have the following labels: needs-qa, QA'd but questions, issues-found.

[gauthierpetetin]

@cortisiko @sethkfman, here's a new proposal, where I removed the QA label check in this commit.

[cortisiko]

@gauthierpetetin Using QA labels on PRs is not limited to the mobile core team; all teams utilize these labels to communicate the type of testing conducted or needed during release testing to the QA engineer. The QA labels help guide us during release testing. We identify based on the label applied to a PR what level of testing is needed during releases. However, if we decide to stop using QA-specific labels, we should have an alternative labeling system to inform the release QA engineers about whether testing has been performed or not. Ideally, engineers would apply this label once testing has been done. For instance, we can use labels to indicate if testing has been completed (automated and or manual), or if the PR doesn't require any testing, such as for documentation or unit test changes.

Anyways what you proposed is fine. We will iron out the details on the proper label soon.

[gauthierpetetin]

As discussed with @danjm @sethkfman @cortisiko @PeterYinusa @vpintorico last Friday, I updated this PR to:

• add checks for these labels in this new Github action: need-ux-ds-review, blocked, stale, DO-NOT-MERGE
• remove the old DONOTMERGE github action as duplicate of this new Github action

Here's the corresponding commit.

[NicolasMassart]

Looks good to me. Added only an error message improvement suggestion.

[cortisiko]

🥇 🥇 🥇

[Cal-L]

Updated PR with main

[Cal-L]

LGTM

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[NicolasMassart]

Looks good to me.