necojackarc / auto-request-review

A GitHub Action that automatically requests review of a pull request based on files changes and/or groups the author belongs to 🤖

Home Page:https://github.com/marketplace/actions/auto-request-review

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Please add support for configuration automatic assignment in addition to reviews

BenHenning opened this issue · comments

Hi. After much searching for an action that can automatically assign reviewers based on file globs, this seems like by far the best choice. However, my team's workflow actually hinges on utilizing assignment for "take another pass/work on this PR" rather than just reviewers. Might it be possible to extend this action's functionality to include a configuration for assigning & marking reviewers for folks that match the criteria to review a particular PR?

Per the code, I think I can go ahead and make this change if there's limited availability to work on the action but it will probably take me a few days before I can make the time for it.

commented

@BenHenning Hi. Thanks for your feature request. If I understand correctly, you'd like to automatically set both "Assignees" and "Reviewers" using the different sets of configuration, correct?

image

For instance, when you make some changes on JavaScript files, you'd like to set "Member A" and "Member B" as "Assignees" while setting "Member C" as a "Reviewer". Something like that?

If that's correct, what I can think of is to make it configurable which type of assignees/reviewers you'd like to automatically assign with this action, "Assignees" or "Reviewers" with something like:

options:
  use_assignees: true # default false - if true, assignees will be set instead of reviewers

Then, you can set up two different workflows using this action. Does it satisfy your use case?

Another way is to provide an assignees section, however, I feel that would make the action a bit too complicated.

Thanks for the follow up @necojackarc! Yes, that would work for our use case.

To provide a bit more clarity (if it's useful): we'd like to preliminarily assign team members to manage and/or initially review PRs who aren't codeowners, but we otherwise rely on codeowners for automatic reviewers.

A separate question that's pertinent to my team adopting this: does the action support assigning from a GitHub team like codeowners does? I see that the action has its own built-in group support, but that's a bit less flexible than GitHub groups since it requires changing the configuration file. If it doesn't have such support, have there been considerations to add it?

commented

@BenHenning Thanks. That's good to know. Then, it should be possible to implement by tweaking this function

async function assign_reviewers(reviewers) {
const context = get_context();
const octokit = get_octokit();
const [ teams_with_prefix, individuals ] = partition(reviewers, (reviewer) => reviewer.startsWith('team:'));
const teams = teams_with_prefix.map((team_with_prefix) => team_with_prefix.replace('team:', ''));
return octokit.pulls.requestReviewers({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number,
reviewers: individuals,
team_reviewers: teams,
});
}

to take an option like use_assiggnees and use some function provided by octokit.pulls to set assignees, instead of reviewers, when use_assiggnees is true.


re: assigning from a GitHub team

That's a good point. I actually didn't know if it worked with GitHub teams; I played around with it and it turned out it didn't -so I added support for GitHub teams to the latest version.

N.B. As the support for assignees isn't yet implemented, this issue hasn't been resolved.

We're seeing a similar issue and use-case. We use codeowners already, but would like to assign individuals from one of the teams. As it stands, adding this github action can add reviewers if we enumerate them in the config, but it removes the codeowners that have already been added.

We need a way to keep the existing reviewers, and I think using this action to put some random team members into assignees would be useful.