[RFE] Allow CODEOWNERS for assignees

[Fryguy]

At the moment, I have usernames for the assignees value, but would prefer if it used CODEOWNERS instead.

I'm not sure the best way to implement this, but I don't think allowing a string in the assignees is acceptable, since there's an actual GitHub user account named codeowners. I was thinking a new parameter named something like assign-to-codeowners: true which would default to false, and which can be optionally combined with assignees to assign to both sets. If you think this is a good feature, I can implement this.

[Fryguy]

I also considered this applying to reviewers as well, but CODEOWNERS are automatically requested for reviewer by GitHub, so I don't think it makes sense to add as an option.

[peter-evans]

Hi @Fryguy

This is probably not something I would want to add the action because I try hard to keep the action simple and not bloat it with features. This kind of feature has other solutions I think. I am curious about your use case and I will try to help you come up with a good solution.

Firstly, I'm interested to know what the use case is for adding codeowners to assignees. When you open the PR, the codeowners are already requested for a review and notified. You can additionally enforce a review from codeowners with a branch protection rule. So what is the benefit of additionally adding all the codeowners as assignees?

... I don't think allowing a string in the assignees is acceptable, since there's an actual GitHub user account named codeowners

I don't understand why a user existing with that name would make it unacceptable to pass a string of assignees. I think it would be perfectly fine to compute codeowners in a separate step and pass them to the assignees input.

Another possible solution is to write a workflow that triggers on pull_request with activity type review_requested. Then you can just fetch the reviewer(s)/team(s) and assign them to the PR. I haven't checked, but for that activity type the reviewer might be extractable from the event context.

[Fryguy]

Hi @peter-evans, thanks for your response.

My use case is that I maintain a large open source project org, and part of our workflow is using assignees to know who owns particular issues. While reviewers are a similar concept, they are more meant for requesting code reviews, as opposed to workflowy/project-management type stuff. We have other things based around assignees, such as weekly issues triage, for example.

In my very specific case, we have an automated dependency updater GitHub Action, and I need to assign a particular person. However, I have duplication in that I've already put that person's name as the codeowner for the dependencies, and so would like to reuse that instead of listing them twice. Additionally, we're considering moving this particular workflow to a central shared repository, and using it in all of our repositories, and so defaulting to the codeowner makes it easier when I have to reuse the workflow in different repos where the codeowner is different.

... I don't think allowing a string in the assignees is acceptable, since there's an actual GitHub user account named codeowners

I don't understand why a user existing with that name would make it unacceptable to pass a string of assignees. I think it would be perfectly fine to compute codeowners in a separate step and pass them to the assignees input.

Sorry, I was talking about a possible implementation, and so was pointing out that if the implementation were to be putting the literal string codeowners into the assignees input, then that would not work because there is a @codeowners user on GitHub. As such, we'd have to have a different implementation, such as a dedicated assign-to-codeowners field