mergify: enable for any pull request

[0xc0170]

Summary of changes

Add mergify bot to all PRs (all branches). The configuration already resides on master but not yet enabled, only been enabled for feature-mergify to test it.

Docs: https://doc.mergify.io/

The configuration should follow our workflow. If it does not, we should fix via new pull request anytime (note: one drawback, the config is fetched from the default branch, in our case master. So even rules for non master, need to be in the config there). The auto merge is disabled, the bot does not have write access to any of the branches anyway. This bot can move labels, post comments.

To verify for each PR, use "Checks" where you can review Mergify conditions.

To disable, just revert this comment - to have all rules only on feature-mergify for instance. Hopefully, this won't be necessary and we tune the rules once we get more PRs involved (compare to few testing we did).

Impact of changes

Migration actions required

Documentation

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[X] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

@bulislaw

[0xc0170]

Notes:

• reviewers count (request review or approvals) need write access (how Github defines this and mergify uses), therefore request for review or approved counts are only valid for write access members. We will fix this in the following days.
  Currently, tech leads and maintainers reviews count, so should work in most cases but will be improved
• default branch config is used always, so even this PR changes to the conflict won't affect the current job (as default branch config is fetched). This is one limitation to be aware of (rules can be applied for specific branches, mergify can rescan PRs so once master is updated). It was requested to be added in mergify-engine issue tracker.
• automerge is not enabled, instead "ready for merge" label once PR is ready. We will still manually merge PRs for the time being. There are couple of other things that should be addressed before we can go to "automerge".

This should minimize the time between workflow stages. If you find an error, please review "Checks" - Mergify rules and let us know what is not working, or just fix it based on the Mergify documentation.

This PR won't have mergify bot active (see 2nd note). Once merged, it will start.

[ciarmcom]

@0xc0170, thank you for your changes.
@bulislaw @ARMmbed/mbed-os-maintainers please review.

[adbridge]

Missing a state:
In 'needs work' and new commits are made --> needs review ?

[adbridge]

Could we also have a needs: ci label here that may need to be removed if travis was restarted during a CI cycle ?

[adbridge]

Same here, may need to also remove needs: ci if present

[adbridge]

Some minor changes needed

[0xc0170]

I added CI label removal.

In 'needs work' and new commits are made --> needs review ?

There is no condition for this at the moment, will check and request this one.
What we can enable is on github, to request new review once PR is updated.

[0xc0170]

There is this condition: https://doc.mergify.io/examples.html#removing-stale-reviews (not yet complete, see below).

there's an issue about similar functionality we want: Mergifyio/mergify#360. I've left there a comment about what can be done.

[0xc0170]

I updated stale reviews update. I added this:

    conditions: []
    actions:
      dismiss_reviews:
        approved: True
        changes_requested: True

Means after the branch is updated, it will dismissed approved/requested changes and send a message about the update.

[adbridge]

LGTM

[adbridge]

CI started

[0xc0170]

One additional stage there - thinking about the updating PR after needs: work state. As we have jenkins pr-head there and its yellow whenever PR is created or updated. It means updated PR is when pr-head is yellow (no success or failure) and PR is in "needs: work" state. Action would be to move from needs work to needs review.

This should go along with dismissed reviews