-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add multiple rules management per branch #42
Comments
Hi @achaussier! What would be your other criteria to merge those Pyup PR? |
For this use case, it's more a filtering criteria, not a validation criteria. Perhaps PR title, PR owner, commit message, ... An example:
My default branch is develop for my projects, so this is the default target for merge and Pyup updates |
I see what you mean. Right now the rules are per-branch, but they could be per-PR. Then you'd need a criterion of 0 reviewers. Not sure GitHub allows that to be declared, but Mergify could support it nonetheless. Those are likely two different features but they could be achievable on their own and then combined to achieve what you want. |
Here's a proposal for the format implementing this: A pull request object would be represented as a JSON/YAML object like this: - assignees: [list of String users]
- labels: [list of String labels]
- review_requests: [list of String users/teams]
- author: <String login>
- base: <String name of the base branch>
- body: <String the pull request body>
- head: <String name of the target branch>
- locked: <Boolean if the PR is locked>
- title: <String title of the PR>
- files: [String list of filenames modified] It'd then pass a list of filters where the first match will give the rules. rules:
…
pull_requests_rules:
- conditions:
- $[?(author.login == \"sileht\")]
- $[*].files[?(filename == \"README.rst\")]
delete_branch: false This is quite powerful, but not that user-friendly. So far I'm unable to find something that would be a good compromise between powerfulness and user-friendlyness. As a second pass, we could also implement GitHub syntax for searching pull requests and issues though I'm not sure everything is useful and the syntax is quite limited. PoCimport jsonpath_rw_ext
pull_request = {
"assignees": [
{"login": "jd"},
],
"labels": [
{"name": "mergemeplease"},
],
"review_requests": [],
"author": {"login": "sileht"},
"base": "master",
"body": "here some text",
"head": "jd:master",
"locked": False,
"title": "My best PR",
"files": [
{"filename": "setup.py"},
{"filename": "README.rst"},
],
}
pull_requests_rules = [
{
"conditions": [
"$[?(author.login == \"sileht\")]",
],
"delete_branch": True,
},
{
"conditions": [
"$[*].files[?(filename == \"README.rst\")]",
],
"delete_branch": True,
},
{
"conditions": [
"$[?(author.login == \"sileht\")]",
"$[*].files[?(filename == \"README.rst\")]",
],
"delete_branch": True,
},
{
"conditions": [
"$[?(author.login == \"jd\")]",
"$[*].files[?(filename == \"README.rst\")]",
],
"delete_branch": True,
},
]
for rule in pull_requests_rules:
print(rule)
for condition in rule["conditions"]:
if not jsonpath_rw_ext.parse(condition).find([pull_request]):
print(" -> %s does not match" % condition)
break
else:
print(" -> match!") Output
|
One think bother me, people have chance to be confuse about why some PR are merged with some condition and some other not. What about manning |
Also with this new system, we can't really known in advance which rule will be used. In the future we will not be able to says |
Sure we can add a rule name. That'd be easier for debugging and printing which rule is being used. I think you know which rule is being used, you just have to take into account that it can change during the lifetime of the PR, and maybe update the check status more often. Or do I miss something? |
During one second, I have imagined, conditions will in the future also contain current 'protection' attributes, but that a bad idea. In the future we will be more something like this ?
|
That makes me think about do we will merge 'all protections and things to do' when multiple rules match ? I think it would simplify a lot complicated configuration, example:
|
Another idea, should be group 'thing todo after merge' into a dedicated section like
|
You cannot have protections (in the GitHub sense) per pull-request, as you know. So that setting should stay where it is. We should add new settings to define custom merge barriers (that might overlap with branch protection). Not sure about grouping, but having something like |
Of course, I called it 'protection', but I'm talking of our future per pull request merge barriers. |
In that case, +1 :D |
After some more thought, here's another draft: pull_requests_rules:
- name: default protection for master
conditions:
- base=master
automerge:
strict: True
required_status_checks:
- continuous-integration/travis-ci
required_approving_review_count: 2
- name: always delete feature branch pull request
conditions:
- head~="^features/"
delete_branch: true
- name: 4.3 backports
conditions:
- labels="backport-to-4.3"
backport_to: stable/4.3
- name: 4.4 backports
conditions:
- labels="backport-to-4.4"
- base=master
backport_to: stable/4.4
- name: 4.5 backports
conditions:
- or:
- labels="backport-to-4.5"
- base=master
backport_to: stable/4.5 Knowing that:
|
I'm just unsure about the readability of "a match can have - in front of it to exclude it". This will show up as a double dash per line. The rest work for me. conditions:
- - or:
- - labels="backport-to-4.5"
- - base=master |
That would rather be: conditions:
- -labels="backport-to-4.5"
- -base=master Knowing the I can also add |
This has been implemented and is available in v2. |
Hello,
First, thanks for this very useful service !
Sometime, for the same branch, we want a different behavior based on some criteria (PR title, user, ...).
For example, I use Pyup to manage my Python dependencies and for these changes, I only want Travis tests pass, but use another criterias for other changes on the same destination branch.
So if it could be possible to manage multiple rules for the same branch, this would be useful.
Have a nice day
The text was updated successfully, but these errors were encountered: