FEATUREOWNERS
fahad19 opened this issue · comments
Background
GitHub has a CODEOWNERS functionality here
Example:
# .github/CODEOWNERS
##
# all files
#
* @global-owner1 @global-owner2
##
# specific file
#
some/file/path.txt @username
This helps automatically assign code reviewers, and wait for their approval before merging any PRs if affected files belong to one of the path patterns defined in CODEOWNERS file.
Enter Featurevisor
Featurevisor, by default, is filesystem based.
You can fine the definitions spec here:
Features also have the concept of environments, and if you have multiple environments (like staging and production), those rules are defined in one single file together:
# features/my_feature.yml
description: My feature
tags:
- all
bucketBy: userId
environments:
production:
rules:
- key: "1"
segments: "*"
percentage: 100
staging:
rules:
- key: "1"
segments: "*"
percentage: 100
Challenge
Having all environments rules defined in one file makes it difficult to make use of CODEOWNERS, because you can't let one group of users own staging rules, while letting another group to own production rules.
There was an exploration of solving this problem in #180, but that still leaves room for abuse.
Proposal
Similar to CODEOWNERS
, a new FEATUEOWNERS
file can be created.
Assuming we care about GitHub only for now, it would be placed in .github/FEATUREOWNERS
next to CODEOWNERS
file.
The spec of the file could be like this:
# .github/FEATUREOWNERS
##
# Everything
#
* @username
##
# Specific feature (all environments)
#
my_feature @username
##
# Specific feature, with specific environments
#
my_feature staging @user-1
my_feature production @user-2
Workflows set up
These are several events that this solution should react to:
- pull_request: assign Feature reviewers to PR automatically when PR is first opened
- pull_request_review, push: check if all required reviewers have approved the PR already
Expectation
I am less opinionated about the full implementation, but my expectation is to have a reusable solution somehow.
So that people who set up Featurevisor projects (which are private repos) can plug this behaviour in with ease.
Once we make it work for GitHub, we can explore a plugin-based solution to this, where GitHub becomes one of the plugins. Leaving room for adding more plugins for other Git hosting providers like GitLab, BitBucket etc.
The solution can live outside of this monorepo.