.github: Add a reset push label workflow

[makubacki]

Description

The current contribution flow requires a push label for a pull request to be merged. Only a user with write access can add the push label such as a maintainer. However, the push label is "sticky" and stays on the pull request from that point on.

It was recently decided that the user adding the push label should always have to explicitly do so prior to merge. If a pull request is updated (by the PR author or, simply with a rebase), someone must reverify the contents and add the push label again. This means push labels will need to be added much more often to PRs.

This prevents a "time-of-check-time-of-merge" torn state in the pull request contribution flow.

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

How This Was Tested

• On edk2 fork

Integration Instructions

• N/A - This only impacts the PR contribution process in the edk2 repository.

[ardbiesheuvel]

Thanks, this looks reasonable to me.

[mdkinney]

When push label is set and passes all criteria, Mergify adds to a queue. If the queue is not empty or the PR is not already rebased, Mergify will rebase the PR and rerun CI to make sure no regressions have been introduced by PRs merged since the last CI check. I think this PR will remove the push label when Mergify rebases, and that will then remove the PR from the queue and the PR will not be merged and a Maintainer will have to set the push label again.

This feature may effectively remove any use of the Mergify queue feature and will require Maintainers to monitor every PR.

Has this PR been tested in a sandbox with Mergify queues?

[makubacki]

Has this PR been tested in a sandbox with Mergify queues?

No. Setting up an actual mergify queue on my fork would be a lot of overhead. I can do that if we'd like, but I'd need to return to it later when I have more time.

However, I did dump the information for a mergify-triggered synchronized trigger type workflow (19030174924) using the GitHub CLI: gh api -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" /repos/tianocore/edk2/actions/runs/19030174924. The actor is mergify[bot]:

  "triggering_actor": {
    "login": "mergify[bot]",
    "id": 37929162,
    "node_id": "MDM6Qm90Mzc5MjkxNjI=",
    "avatar_url": "https://avatars.githubusercontent.com/in/10562?v=4",
    "gravatar_id": "",
    "url": "https://api.github.com/users/mergify%5Bbot%5D",
    "html_url": "https://github.com/apps/mergify",
    "followers_url": "https://api.github.com/users/mergify%5Bbot%5D/followers",
    "following_url": "https://api.github.com/users/mergify%5Bbot%5D/following{/other_user}",
    "gists_url": "https://api.github.com/users/mergify%5Bbot%5D/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/mergify%5Bbot%5D/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/mergify%5Bbot%5D/subscriptions",
    "organizations_url": "https://api.github.com/users/mergify%5Bbot%5D/orgs",
    "repos_url": "https://api.github.com/users/mergify%5Bbot%5D/repos",
    "events_url": "https://api.github.com/users/mergify%5Bbot%5D/events{/privacy}",
    "received_events_url": "https://api.github.com/users/mergify%5Bbot%5D/received_events",
    "type": "Bot",
    "user_view_type": "public",
    "site_admin": false
  },

I've updated the workflow to only run when the triggering_actor is not mergify[bot].

[mdkinney]

That may resolve the concern. The Mergify config.yml files was updated this year to add the update_bot_account and use the tianocore-issues account to perform rebase operations.

https://github.com/tianocore/edk2/blob/6c6d4d2d5205ff62e66b45e2bccf00094b55dd70/.mergify/config.yml#L30C1-L36C41

queue_rules:
  - name: default
    queue_conditions:
      - base~=(^main|^master|^stable/)
      - label=push
    merge_method: rebase
    update_bot_account: tianocore-issues

Not sure if the account label that leaves a message or the actual account id for account that perform the rebase would be a better filter.