mergeable
mergeable copied to clipboard
comment when mergeable failed for X days
Is it possible to define multiple schedule.repository
entries? I have two different usecases when I would like to use it for, but I am not sure what should be the right syntax?
- Comment when PR stale for 20 days
- Comment when mergeable failed and nobody fixed it for 1 day
All I know is when I had two - when: pull_request.*
entries, only the second one was recognized and the first one was completely ignored?
@pkuczynski you should be able to define multiple `- when: pull_request.*' now, you'll need to name each entry in order to achieve it effectively. something like this:
- when: pull_request.*
name: "validate dependencies"
validate:
- do: ...
- when: pull_request.*
name: "Validate labeling"
validate:
- do : ...
as for schedule.repository
use case, we currently don't have functionality to validate mergeable failed
or nobody fixed it for 1 day
Just to better understand the use case:
for "mergeable failed", are you thinking of check
with failed status?
fot nobody fixed it for 1 day
, i am assuming that we check if the failed check
is one day old. right?
Edit: Sorry, i didn't answer your question. The answer is, you should be able to have multiple schedule.repository
but the only validator available for that event right now is "stale"
So my initial use case was to post a comment whenever the validation fails, so the PR author would receive an email notification that something is not complete with his PR.
I have two types of checks:
- labels, milestones, assignees, etc - which only org members can check
- description, files dependencies etc - fixable by everybody
Initially, I implemented the commenting on validation failure, but then after initial comment, when I started to add a milestone, label, etc, every time mergeable was posting a comment every time something changed until I fixed all validations. This was highly annoying and you can see it in this PR: https://github.com/rvm/rvm/pull/4963
So I thought if there would be a way of delaying the comments by some time (ideally few mins, but 1 day could also work), that would solve this problem...
@pkuczynski i see, okay. We can implement a configurable throttling function for comments. The caveat with this approach however would be that, if no activity takes place in the PR (label, editing, milestone, etc..), the new comment will never appear. Is that something you are okay with?
I think the best would it be to add such functionality to when: schedule.repository
...