Support for key value lookup file on front matter reviewers about pr-helper HOT 9 CLOSED

I like the Jekyll Authors implementation.

If a PR comes in with an owner: value that isn't found in in authors.yml, it should also create a failing check.

from pr-helper.

Let's settle on this syntax for Authors file:

# Author details.
Author Name:
    name: Author Name
    email: [email protected]
    web: http://twitter.com/account
    github: githubusername

from pr-helper.

@wbsmolen have a read of this and let me know if you think this solution would work for the problem we were discussing.

from pr-helper.

Thanks, great idea on the failing check too.

from pr-helper.

Is this bot mutually exclusive with the built-in codeowners functionality? Leveraging codeowners to assign review to a github team could be useful.

E.g.: Take Arc for servers' content in the DHT repo. The page owner would likely be Islam Gomaa, but ideally the entire vteam is assigned to a PR opened against its content.

The branch protection is still requiring only a single reviewer, but this would include more folks in the content review process. Plus, if Islam (sticking to my eg) is out of office, PRs against his content are not blocked.

You could implement this front matter parsing feature to allow for multiple authors, but a) that sounds complicated and b) having the github teams/groups capability would be beneficial.

from pr-helper.

The reviewer functionality can be leveraged by either/both:

1. Parsing the front-matter where a comma delimited list of owners will be set as the reviewers. The current implementation should work with teams but I haven't tested that. The future state that this issue proposes should still allow for that too in the author file in theory.
2. If you have a CODEOWNERS file, then this will be handled natively by GitHub, and can be used in addition to the front-matter parsing. This natively supports both individuals and teams.

Regardless of which method assigns the reviewers, the Bot/Action can be configured with either:

1. Set prmerge-requirereviewcount = -1 will disable the minimum review count and instead require that there are no pending reviewers on the PR. Once all reviewers have approved it would proceed with the merge.
2. Set prmerge-requirereviewcount = X will require that a minimum of X reviews are approved before auto merge will run. There may still be other reviewers requested. This is similar to the minimum reviewer functionality in GitHub Branch Protection. Unfortunately I am still looking for a way to pull that setting via the API. The value of X should match your Branch Protection Rules.

So I believe the scenario you describe is catered for with this configuration regardless of which method you use to assign reviewers. Actually using a combination of both could be beneficial as it would increase awareness of content changes to a larger group and allow backup coverage.

from pr-helper.

Progress update - 2020-07-26

Initial dev work done on reading Author file and retrieving GitHub user. Implementation into work flow still required.
TODO: Look at leveraging artifacts to avoid API call to file contents https://developer.github.com/v3/actions/artifacts/

from pr-helper.

Progress update - 2020-07-26 - Feature Preview testing

Preview feature testing will be completed in the Dev breach tomorrow. This initial release will perform an API call against the repo to get file contents. Am looking into using Action/Checkout on default branch and the Artifacts to reduce the chance of rate limiting on some membership levels.

from pr-helper.

Initial support for this is released. Please open new bugs/features and reference this issue where relevant

from pr-helper.