Enforced merge policies on pull requests
Problem to solve
It's currently impossible to have different merge policies on pull requests in function of what file is being updated.
It would be nice to have different merge policies in function of whether a *<PATTERN_1>*
file or a *<PATTERN_2>*
file is being update.
In CI we already can do that, trigger the pipeline only if a specific type of file is being update. The idea is the same but for the merge policies this time.
Intended users
Infrastructure engineers / SREs
Further details
Use case: you have a kubernetes
repo where all your kubernetes configuration files are. And you have in that repo one configuration file per cluster you have. So imagine you have 3 staging clusters / 3 prod clusters and 3 dev clusters, then you would have 9 cluster configuration files.
Now you don't want to split those configuration files at a branch level (like master branch for prod, stage branch for stage...etc) but you still want different merge policies in function of which file is updated, say:
- CI succeed + review when a
*prod*
configuration file is updated - CI succeed when a
*staging*
configuration file is updated - nothing required when a
*dev*
configuration file is updated
The idea is to make easier for developer to push changes to staging
and dev
, without having to wait each and every time for someone to review the change, and still make sure prod
push are enforced.
Proposal
This policy-bot for github does the job: https://github.com/palantir/policy-bot
Have .policy.yml
file in the repo that would drive the merge policies.
Permissions and Security
To edit the file that would drive the merge policies you would need maintainer access on the repo.
Documentation
Unknown
What does success look like, and how can we measure that?
The rules are properly applied and a user can/can't automatically merge a change in function of what he/she updated and the policy rules associated to the updated files.
What is the type of buyer?
Unknown