Add merge_group trigger on tests and deployment#10275
Conversation
|
The build for this PR is no longer available. Please visit https://builds.jabref.org/main/ for the latest build. |
|
I go with these settings:
Collecting more than 1 PR, but the merge queue should kick-off after 5 minutes if no more PRs are coming in. This should leave us enough discusion time, but also quick enough to keep things moving. |
|
Merge queue takes the branch protection rules serious:
We like the merge queue feature. We like that new commits dismiss old reviews. We like two have two reviewers on a PR. To make use of the merge queue feature, we change the formal number of required reviewers to 1, but "enforce" the two-reviewer-rule manually. |
|
Checking after change to 1 required reviewer:
|
|
Link to merge queue: https://github.com/JabRef/jabref/queue/main |
|
Screenshot merge queue:
|
|
Due to the cancelling of currenet builds, we needed to adapt the settings. Please vote up https://github.com/orgs/community/discussions/63136
|
|
We discussed whether we should remove the cancelling of previous jobs. However, we weigh the cancelling of previous runs higher then having a "fast" merge queue. |
|
Queue with 2 PRs (and concurrency limit 1)
|
|
How a merge looks like:
Commit:
|
|
There is no indication whether a PR is selected to put into the queue. Only if the pre-conditions are fulfilled and GitHub put the PR into the merge queue, there is a different icon. The yellow-marked PR below is set to be put into the merge queue. The other PR below is not in the merge queue.
|
|
Drawback: If a PR was taken out of the merge queue, there is no notification. |
|
We have timeout issues:
Therefore we increased the timeout from 60 to the maximum of 360 minutes |
|
The merge queue seems to have issues with status reporting sometimes:
|
|
It hang because of an error in the YAML file:
|
|
Interestingly, there is no cancelling of merge builds when new commits are added. These are just ignored:
|
|
Note that all requires status checks have to be checked by the merge queue: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions |
In DevCalls (or gatherings), we often say: "Just let the tests pass, then merge". For this scenario, the merge queues of GitHub have been invented. Docs available at https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#triggering-merge-group-checks-with-github-actions.
To put this live:
Mandatory checks
CHANGELOG.mddescribed in a way that is understandable for the average user (if applicable)