Check if reviewers are not commiters

[dudu]

There are some compliance restrictions that demand segregation of responsibilities, so the same person can't code, approve and deploy a change, GitHub doesn't assess this type of constraint, so on the scenarios above only Scenario A should be mergeable.

Scenario A
Given a PR X, created by John
With commits by John and Lisa
Bob and Mary, review and approve the PR X
The PR is compliant

Scenario B
Given a PR Y, created by John
With commits by John and Lisa
Lisa and Mary, review and approve
The PR Y is not compliant

At least in my organization, it will be useful, what do you people think? Can I make a PR?

[shine2lay]

@dudu this seems like a very specifc use case, do you have any idea on how the setting would look like for this use case?

[dudu]

Yes, in companies regulated by Sarbanes–Oxley Act, to avoid internal frauds, one single person can't be capable of making some change on application and deliver it. In more traditional IT environments this control is made by segregating roles. i.e:

• John is a developer, Anna is a developer, and Ben is a Deployer. So John and Anna never could make some change and deliver it, because only John has access to deploy.

This model requires people only to "press the deploy button". Instead of that, I want to implement automatic control. So John codes, Anna, and Ben review the code, and as soon it was approved it follow the continuous delivery. The segregation of roles is dynamic, since the person who codes (committed) is different from the reviewers I'm compliant with.

[dudu]

A suggestion of config could be in Validators/Aprovals

- do: approvals
  min:
    count: 2 # Number of minimum reviewers. In this case 2.
    message: 'Custom message...'
  required:
   ...
  block:
    ...
  limit:
    non_committers: true # when the option is enabled, check if the approvals are not in the committers list
   

[jusx]

Hi @dudu, was not aware that this kind of automatic control was an option for SOX compliance. Alternatively, if one wanted to automate segregating roles, it is also feasible to create a validator that uses GH teams as a way to identify roles: EM, Developer, etc and enforce validation that way.

[dudu]

@jusx yes, I will already need "fixed" roles, my wish was something more fluid and not with pre-defined roles.

[shine2lay]

@dudu

A suggestion of config could be in Validators/Aprovals

that settings looks great to me.