Understanding rules evaluation

[AlekSi]

I'm having a hard time understanding what triggers rules evaluation and what triggers actions.

The only bit of information about that I was able to find is there: https://docs.mergify.com/workflow/writing-your-first-rule/#understanding-mergify-rule-conclusions

Mergify continuously evaluates your rules whenever a pull request is updated or modified. When a rule's conditions are met, Mergify triggers the corresponding actions.

I think that "whenever a pull request is updated or modified" is a bit too vague. For example, that does not include edits of the PR title or description. It would be nice to have a list of things that trigger rules evaluation in the documentation.

Actions triggering is even more confusing. I tried a following configuration:

pull_request_rules:
  - name: "On conflict"
    conditions:
      - "conflict"
    actions:
      comment:
        message: "@{{author}} this pull request has merge conflicts."

I created a PR. Then, I pushed a commit to the base branch to create a merge conflict. The comment was added to the PR. So far, so good. But then I wasn't able to make this comment be added again by pushing a commit to either the base branch or PR branch. It seems like rules are evaluated on pushes to the PR branch, but actions are executed only when rules previously evaluated to false and now evaluate to true. In other words, it is an edge-triggering system, not state-triggering. Is it true? Is it true for all rules, conditions, and actions? Again, it would be nice to have it documented.

[AlekSi]

(as a side note: typing true in the search box on https://docs.mergify.com makes the page disappear with SyntaxError: JSON Parse error: Unrecognized token '<' error in the console)

[jd]

Thanks, I've opened a bug on our side for fixing.

[jd]

I think that "whenever a pull request is updated or modified" is a bit too vague. For example, that does not include edits of the PR title or description. It would be nice to have a list of things that trigger rules evaluation in the documentation.

It does. What makes you think it doesn't?

I created a PR. Then, I pushed a commit to the base branch to create a merge conflict. The comment FerretDB/merge-queues#1 (comment) to the PR. So far, so good. But then I wasn't able to make this comment be added again by pushing a commit to either the base branch or PR branch. It seems like rules are evaluated on pushes to the PR branch, but actions are executed only when rules previously evaluated to false and now evaluate to true. In other words, it is an edge-triggering system, not state-triggering. Is it true? Is it true for all rules, conditions, and actions? Again, it would be nice to have it documented.

Yes, you're right; it's edge-triggered indeed (I never heard that expression but I'll be sure to include it in the docs 😄).
I'll make sure it's documented (I'm working on it).

[AlekSi]

So is it a recent bug or a recent fix? Maybe the definition of "request for review" changed recently? Because now it seems to mean "pending request for review", and before it seem to mean "request for review present in any state, including 'approved' and 'changes requested'". It seems like https://docs.mergify.com/workflow/request-reviews/#basic-assignment would fail now, too.

[jd]

Nothing changed as far as I can tell on Mergify's side (can't say for GitHub though), and the example still works as expected.
It just does not match what you expect, I guess.
Review states are not checked if you don't ask for them to be checked in conditions.

[AlekSi]

But… that configuration worked before for several months.

To put it another way: should this example re-request review after each review? That's unlikely because that's pretty useless. But that example is not that different from my configuration.

[jd]

Yes, it does re-request review. We actually use it internally for months.

You're claiming something changed, but do you have an actual example of the previous behaviour that you saw?
I went ahead and looked at PR such as FerretDB/FerretDB#3417 and it shows that Mergify request the review from "a team" each time a review is done on behalf of it.

[AlekSi]

/o\ Sorry, that was just me being blind. Thank you!