mergify: Add merge automation #70
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add PR merge automation using [Mergify](https://docs.mergify.com). This configuration is similar to merge automation enabled on the `instructlab/instructlab` and `instructlab/instructlab-bot` github repositories. While it is still possible to merge by hand, the intent of this automation is merge things automatically once they meet specified criteria. This should be able to handle merges the vast majority of the time. Some exceptions include, but aren't limited to: - Changes to the mergify config (these won't get auto merged) - Changes to fix something urgently broken - Dealing with various infrastructure outages Mergify has a very flexible configuration for defining merge policy. The configuration proposed here includes: - Require approvals from 2 maintainers - There are no outstanding review requests. For example, if someone requests review from a specific person, the PR will not get merged automatically until that review is given or the review request is dismissed. - There are no "changes requested" reviews still pending. If a past review requested changes, the PR will not get automatically merged until that person reviews again. - There are no prohibited labels set on the PR, including `hold`, `do-not-merge`, or `needs-rebase`. - Expected CI jobs are all passing. This is the most verbose part of the configuration, because we have to define when we expect the CI job and when we don't. This is based on what files changed, and the pattern list must stay in sync with the github workflow configuration. On any given PR, you can check on Mergify's analysis of the PR against the merge criteria by clicking the `Details` link next to Mergify's line item in the list of checks - the same place where CI results show up. Signed-off-by: Russell Bryant <[email protected]>
|
Looks like the same policy as the instructlab one - I'd expect the same policy against repos, so +1 |
markmc
approved these changes
Jul 9, 2024
|
I'd like to hold off on this for a while. I'm leaving it up as a draft because I think it's worth revisiting at some point. |
shivchander
approved these changes
Jul 16, 2024
@russellb Any reasons for hold on this? |
mostly because we haven't been following the policy proposed here (requiring 2 reviews) so I'd rather wait until the repo settles to where we're ready to use more rigid merge requirements |
|
I'd be in favor of moving forward with this if possible |
nathan-weinberg
requested changes
Aug 30, 2024
|
talked with Russell offline. Closing in favor of #262 |
jwm4
pushed a commit
to jwm4/sdg
that referenced
this pull request
Dec 13, 2024
This came up in review on instructlab#70, so document the preferred capitalization. Signed-off-by: Russell Bryant <[email protected]>
jwm4
pushed a commit
to jwm4/sdg
that referenced
this pull request
Dec 13, 2024
docs: Update publish strategy to include Ollama publishing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add PR merge automation using Mergify.
This configuration is similar to merge automation enabled on the
instructlab/instructlabandinstructlab/instructlab-botgithubrepositories.
While it is still possible to merge by hand, the intent of this
automation is merge things automatically once they meet specified
criteria. This should be able to handle merges the vast majority of
the time. Some exceptions include, but aren't limited to:
Changes to the mergify config (these won't get auto merged)
Changes to fix something urgently broken
Dealing with various infrastructure outages
Mergify has a very flexible configuration for defining merge policy.
The configuration proposed here includes:
Require approvals from 2 maintainers
There are no outstanding review requests. For example, if someone
requests review from a specific person, the PR will not get merged
automatically until that review is given or the review request is
dismissed.
There are no "changes requested" reviews still pending. If a past
review requested changes, the PR will not get automatically merged
until that person reviews again.
There are no prohibited labels set on the PR, including
hold,do-not-merge, orneeds-rebase.Expected CI jobs are all passing. This is the most verbose part of
the configuration, because we have to define when we expect the CI
job and when we don't. This is based on what files changed, and the
pattern list must stay in sync with the github workflow
configuration.
On any given PR, you can check on Mergify's analysis of the PR against
the merge criteria by clicking the
Detailslink next to Mergify'sline item in the list of checks - the same place where CI results show
up.
Signed-off-by: Russell Bryant [email protected]