kentaro-m / auto-assign Goto Github PK

Describe the bug
Hello,
I was trying to enable this using GitHub actions. Would it be possible to do that without installing the app?

To Reproduce
Steps to reproduce the behavior:

1. Create main.workflow and yml file as instructed.
2. Try opening a Pull request.

Expected behavior
PR should be assigned to user in the yml file.

Screenshots
test repo: https://github.com/bdwyer2/gh_actions

Desktop (please complete the following information):

• OS: [e.g. iOS]: MacOS
• Browser [e.g. chrome, safari]: Firefox
• Version [e.g. 22]: 68.0.2

Describe the bug
The pull request owner was requested as reviewers. But, it is unable to request a review from the pull request owner on the specification of GitHub.

https://developer.github.com/v3/pulls/review_requests/#create-a-review-request

Currently, if failed to review request, throw an error and exit process. As a result, not add assignees to pull request.

To Reproduce
This error was confirmed from the sentry log, it is not what I actually experienced.

Expected behavior
The pull request owner is not requested as reviewers.

Is your feature request related to a problem? Please describe.
I would like auto-assign bot to assign reviewers after PR is ready and skipKeywords(e.g. "wip") are removed.

Describe the solution you'd like
Hooks events that PR title is changed and if skipKeywords are removed, do auto-assign.

Hi! I am just exploring the auto-assign bot and I see I can configure groups to assign for reviews. However, these have to be defined in the config file. Since we already manage our groups in Github teams, would it be possible to reference only the Github team names in the config? Or is this an already existing feature? Thanks!

Is your feature request related to a problem? Please describe.
Presently whilst the owner of the repository is excluded from the possible assignees/reviewers, the person who opened the pull request is not.

Describe the solution you'd like
An option to exclude the opener of the pull request.

Describe the bug
According to the measurement result of StatusCake, the number of response timeout on running app at Glitch is increasing.

Is your feature request related to a problem? Please describe.
It is normally the case, while working with monorepos, for multiple teams to own the same codebase but work on different packages (e.g. lerna, yarn workspaces, etc.). It'd be great to provide some support for these use cases where a group would be assigned to a pr if a specific glob matches.

Describe the solution you'd like
Extend the group feature so that if a specific glob produces matches then the group is requested a review.

useReviewGroups: true

# A list of reviewers, split into different groups, to be added to pull requests (GitHub user name)
reviewGroups:
  groupA:
    - reviewerA
    - reviewerB
    - reviewerC
  groupB:
    - reviewerD
    - reviewerE
    - reviewerF

paths:
  groupA: 
    - "./packages/pkg-a/**/*.*"
    - "./glob/for/shared/files"

  groupB: 
    - "./packages/pkg-b/**/*.*"
    - "./glob/for/shared/files"

Additional context
In the given example,
if a change happens on ./packages/pkg-a/**/*., then we would assign groupA;
if a change happens on ./packages/pkg-b/**/*., then we would assign groupB;
if a change happens on /glob/for/shared/files, then we would assign both groupA and groupb;

I'd like to investigate a propose a pull request to implement it.

Is your feature request related to a problem? Please describe.
We can have multiple group of reviewer (e.g one for a specific set of files or work), so making use of the group feature looks like it's appropriate...

But we may want that for some files (e.g .js, or a certain path / directory), as does github's codeowner feature does it we pick reviewers from these appropriate groups.

Codeowner is not really the way to go for that, as we want to randomly pick reviewers from such a group instead of always relying on the same reviewers.

Describe the solution you'd like
Something that allows to configure when a group should be used when picking random reviewers.

Is your feature request related to a problem? Please describe.

Our team uses this this action heavily, but we'd like the ability to override the auto-assignment for certain PRs, in particular ones where a developer knows precisely who should review a PR. Right now we often have to remove an auto-assigned reviewer, which creates unnecessary notifications. The existing skipKeywords feature only appears to check the PR title instead of also checking the PR body, which means we're forced to alter our PR title, and thus our squashed commit message title, just to conform to this action's requirements.

Describe the solution you'd like

Either skipKeywords should check the PR's body for matching keywords or there should be a separate skipBodyKeywords feature that matches based on body text.

Describe alternatives you've considered

We can continue working around this by manually removing reviewers.

Additional context

I'm mostly interested in knowing whether this feature is something you think is valuable. If it is, I'm happy to send a PR to make the change 😄

Why does the bot doesn't handle draft PRs? I know it doesn't make sense for reviewers as this is draft and you don't want to assign, but if you have "addAssignees: author' in the config file it should not ignore the draft PR and assign the assignee.

Is your feature request related to a problem? Please describe.
I sometimes get a report on the problem that auto-assign can not add a pull request owner as a reviewer.

Related issue: #63 #50

Describe the solution you'd like
Add a description on README.md that it is unable to request a review to the pull request owner on the specification of GitHub.

https://developer.github.com/v3/pulls/review_requests/#create-a-review-request

Is your feature request related to a problem? Please describe.
now, many repo already have the OWNERS file in the repo,include the people who can review. now we only can add reviewer by auto_assign.yml,can auto_assign.yml to read OWNERS file get the reviewer ?

Describe the solution you'd like
auto_assign.yml to read OWNERS file get the review people.
for example , auto_assign.yml

# Set to true to add reviewers to pull requests
addReviewers: true

# Set to true to add assignees to pull requests
addAssignees: false

# A list of reviewers to be added to pull requests (GitHub user name)
reviewers:
  - OWNERS # the file path and name

# A number of reviewers added to the pull request
# Set 0 to add all the reviewers (default: 0)
numberOfReviewers: 0

# A list of assignees, overrides reviewers if set
# assignees:
#   - assigneeA

# Set to true to add reviewers from different groups to pull requests
# useReviewGroups: true

# A list of reviewers, split into different groups, to be added to pull requests (GitHub user name)
# reviewGroups:
#   groupA:
#     - user1
#   groupB:
#     - user2

Is your feature request related to a problem? Please describe.
Issues also need assignees.

Describe the solution you'd like
Some opt-in system (to not disrupt existing users) that would also have the bot assign issues

Describe alternatives you've considered
There's https://github.com/andrewlock/auto-assign-issues but it feels a bit strange to need both for something fairly similar. It also doesn't seem to work, and doesn't have numberOfAssignees

Is your feature request related to a problem? Please describe.
Conditional statements are increasing to validate configuration files (auto_assign.yml).

Describe the solution you'd like
Validating configuration file using hapijs/joi

c.f. https://github.com/probot/stale/blob/master/lib/schema.js#L1-L44

Is your feature request related to a problem? Please describe.
Currently listing a Github team assigns the whole team to the pull request, when in reality what I am hoping for is individual members in the team to be assigned.

Describe the solution you'd like
Can we define the team name org/team and X number of reviewers will be chosen from the github team.

Describe alternatives you've considered
Listing each individual member in a org/team. But then you'll have multiple list of teams to maintain.

Additional context
I am not entirely sure if this is already available and I am just listing the team incorrectly in the auto_assign.yml. At the moment it assigned the whole team to the pull request, which is not exactly what I was looking for. I only needed two members in the team.

Describe the solution you'd like
When user opens a new PR, we would like him to be auto assigned to this PR as its owner.
Is there such support in this bot?

Describe alternatives you've considered
Currently we do it manually on PR opening.

Additional context
It helps to see in PR list who the PR belong to.

Just wondering if
a) can this be installed on Github Enterprise and
b) if you plan to provide documentation to possibly clone and run on a GHE server?

We are currently on version 2.16.6 of GHE.

Please let me know if this is the incorrect method to ask such a question.

Thanks.

Hi kentaro-m,
I have opened a PR for the requested functionality in this ticket. Sadly the CircleCi build is failing with a confusing error:
Bad response: 422 {"message":"Couldn't find a repository matching this job.","error":true}

Is your feature request related to a problem? Please describe.
I find myself in the situation where there is a rift in the engineering team I am working in (which I understand is a common problem). The divide in knowledge and practices lies along the separation of our offices.

Describe the solution you'd like
I therefore looked for a tool that could help us to share the knowledge between offices. The auto_assign bot was perfect for our needs, except that we specifically want to select people from each office, or "group", to review any given PR. The theory is that selecting reviewers from each group will help us bridge the gap in knowledge and bring the two teams closer together.

Describe alternatives you've considered
I have designed the implementation to leave all the current functionality intact, and add review/assignee groups on top of your current code.

Let me know what you think!

Describe the bug
When running the prebuilt action i get the following error:

07:30:12.168Z ERROR event: Cannot read property 'length' of undefined (id=....)
  TypeError: Cannot read property 'length' of undefined
      at Object.chooseUsers (/app/lib/util.js:9:20)
      at /app/lib/handler.js:57:40
      at step (/app/lib/handler.js:32:23)
      at Object.next (/app/lib/handler.js:13:53)
      at fulfilled (/app/lib/handler.js:4:58)
      at process._tickCallback (internal/process/next_tick.js:68:7)
  --
  event: {
    "event": "pull_request.opened",
    "id": "....",
    "repository": "..."
  }

Config:

# Set to true to add reviewers to pull requests
addReviewers: true

# Set to true to add assignees to pull requests
addAssignees: false

# A number of reviewers added to the pull request
# Set 0 to add all the reviewers (default: 0)
numberOfReviewers: 3

# Set to true to add reviewers from different groups to pull requests
useReviewGroups: false

reviewers:
  - userA
  - userB
  - userC


# Set to true to add assignees from different groups to pull requests
useAssigneeGroups: false

To Reproduce
Sadly its a private repo and i am not sure how to reproduce this. If you cant help with the provided information plz let me know. I will try to create a public repo to showcase the error

Expected behavior
With the provided config this should simply work

Describe the bug

I've listed a team in the reviews as org/team-name and it does not appear to be added as a reviewer.

To Reproduce

1. Include a team in the reviewers list

Expected behavior

I expect the team to be added as a reviewer.

Is your feature request related to a problem? Please describe.
During the initial exploration of applying this bot to the project I work on, someone expressed concern of what would happen when they're on vacation, sick, or otherwise unable to review a PR. This is an important question for all projects, but especially open-source projects where devs might be taking breaks frequently and sporadically.

I'd like there to be a "Vacation Mode" where no PRs are assigned to you even if you're still on the PR reviewers list.

Describe the solution you'd like
I discussed this idea initially with @kentaro-m in a Spectrum post and I like the solution of leveraging the github API around the "busy" checkbox in the user's profile:

If I were you, I would implement it using the User Status API. If you use the indicatesLimitedAvailability fields, you can get the status of whether a user is busy.
https://developer.github.com/v4/object/userstatus/

Describe alternatives you've considered
In my initial post in that Spectrum thread I proposed these 2 solutions, but wasn't really happy with either from a usability standpoint:

1. Making people edit the config to remove themselves before they leave on vacation. This is a little rough because then you need to remember to edit the config everytime you go away.
2. If someone hasn't reviewed a PR within a certain number of days, note them as away and re-assign randomly. I like this idea, but I'm not sure how tricky it would be given the way the bot works

I've checked this bug #63 but it didnt work as well.

I am already facing the same problem I already installed the bot into out private repository with:

addReviewers: true
# Enable to add reviewers as assignees.
addAssignees: true

reviewers: 
  - deda9

skipKeywords:
  - wip

numberOfReviewers: 0

but we didnt merge this into our master branch yet, might be that the problem?

Describe the bug
A clear and concise description of what the bug is.

auto-assign is not making assignments on repositories configured in the GitHub app and with a compliant .github/auto_assign.yml present.

To Reproduce

1. Submit a PR to an affected repo
2. Observe that no reviewers or assignees are added

Expected behavior

Reviewers or assignees are added.

Screenshots

These are internal repos but I can tell you that the repo is on the list in https://github.com/organizations/<orgname>/settings/installations/324587.

Additional context

The repos that are working are the repos that had an auto-assign config in them when it was enabled. Others were enabled and then the configuration was added: those are the ones that aren't working. It would be laborious to toggle for all of the repos we've enabled so I want to do that only as a last-ditch effort.

Describe the bug

The owner of the PR was set as an assignee.

To Reproduce

1. Have a configuration which lists two assignees, has numberOfAssignees: 1 , and addAssignees: true.
2. Submit a PR as one of the two assignees.
3. Observe that 50% of the time, the submitter is set as assignee.

Expected behavior

The PR owner should not be set as an assignee or reviewer.

Additional context

Looking at the code, I don't really see how this is possible on a quick glance.

Describe the bug
Currently, the auto-assign app has permission too much to run it.

I added permissions (read access for repository contents and single file) to resolve Issue #31 that the app doesn't have permission to call GitHub API in the private repository to get config file (.github/auto_assign.yml).

But, when I was pointed out from the user, I noticed that the app need only permission for the single file (.github/auto_assig.yml).

I want to update proper permission.

Expected behavior
Update the permissions with following:

Current:

• Repository contents: Read Only
• Pull requests: Read & Write
• Single file (.github/auto_assign.yml): Read Only
• Repository metadata: Read Only

New:

• Pull requests: Read & Write
• Single file (.github/auto_assign.yml): Read Only

Additional context
Before actually changing, I will check whether it works normally in the test environment.

When updating the permission, Github will be sent email to all install users as to whether permission updates is permitted.

Describe the bug
A clear and concise description of what the bug is.

Sometimes with some pull requests, auto-assign will assign two reviewers when three are requested. We also maintain two groups.

To Reproduce
Steps to reproduce the behavior:
1.Add the auto-assign GitHub app to a repo.
2.Submit a PR against the repo.
3.Sometimes auto-assign will assign two reviewers, sometimes it will fail to assign any at all.

Expected behavior
Assignment of all 3 reviewers should always happen consistently.

Additional context
A sample .yml file that closely mirrors our github repo setup.

addReviewers: true

numberOfReviewers: 1

useReviewGroups: true
reviewGroups:
  groupA:
    - user1
    - user2
  groupB:
    - user3
    - user4
    - user5
  groupC:
    - user6
    - user7
    - user8
    - user9

Is your feature request related to a problem? Please describe.
In a project with many developers in different teams for different parts of the project it is difficult/impossible to use auto_assign.

Describe the solution you'd like
Assignment of teams/people based on words in the title of the PR. For example:

reviewWordGroups:
    - words: ['security', 'secure']
      reviewer: ['org/security', 'org/devop']
    - words: ['tests']
      reviewer: ['org/testing']

Describe alternatives you've considered

Additional context

Describe the bug
I have already config as the doc but still not find actions when run CI

addReviewers: true
addAssignees: author
numberOfReviewers: 0
numberOfAssignees: 1
useReviewGroups: true
reviewGroups:
  groupA:
    - tanphamhaiduong
useAssigneeGroups: false

...
env:
  GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
  CI: true
...
add-reviews:
    runs-on: ubuntu-latest
    steps:
      - uses: kentaro-m/[email protected]
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"

Expected behavior
It can find actions

Screenshots
If applicable, add screenshots to help explain your problem.

Describe the bug
I enable auto assign, but it does not work on any pull requests

To Reproduce
Steps to reproduce the behavior:

1. enable auto-assign following documentation
2. configure .github/auto_assign.yml

addReviewers: true

addAssignees: false

reviewers: 
  - clakech

skipKeywords:
  - wip

numberOfReviewers: 0

Expected behavior
Auto assign should auto assign clakech to the newly created pull requests

Screenshots
Auto assign is configured with above config file .github/auto_assign.yml

Additional context
private repository

Describe the bug
A clear and concise description of what the bug is.

This error is thrown when auto-assign do not have permission to use the API. auto-assign uses getContents API to get .github/auto_assign.yml.

I have confirmed that this error has occurred in the private repository. It seems that auto-assign can access the configuration file, even if you do not have permissions in the public repository.

Previously, auto-assign did not have the permission to use getContents API. I was pointed out it from the user, added the permission.

To Reproduce
Users who have been using this application before changing permissions need to reinstall auto-assign.

Expected behavior
auto-assign can read the configuration file.

Screenshots
I added the permission after the user pointed out.

Describe the bug

On a repository not suffering from #38, auto-assign bot will periodically not add reviewers/assignees.

To Reproduce

• Add the auto-assign GitHub app to a repo.
• Submit a PR against the repo.
• Sometimes auto-assign will act immediately, sometimes it won't ever act.

Expected behavior

Always should act within a certain period of time, say 1-2 minutes.

Additional context

I speculate that this might be a requests-queueing problem combined with an API limit problem but it seems like that's something that Probot framework would handle…

Describe the bug
I installed the app, but nobody is being assigned.

Expected behavior
Users are assigned to PRs.

Additional context
I wasn't sure if it needed to be deployed manually or this is a hosted app.

Is your feature request related to a problem? Please describe.
Sometimes the auto-assigned user is not available (Vacation, sick, in training, at a conference, etc...)

Describe the solution you'd like
A way to trigger auto-assign to choose a new, randomly selected reviewer.

Describe alternatives you've considered
You could use github suggestions, but that doesn't help you avoid the problem of knowledge siloing.

Adding an option to rotate through the list of reviewers so that everyone is guaranteed to review the same number of pull requests.

Probot comes bundled with a client for the Sentry exception tracking platform. To enable Sentry:

1. Install Sentry from Marketplace (with 10k events/month free) or host your own instance (Students can get extra Sentry credit)
2. Follow the setup instructions to find your DSN.
3. Set the SENTRY_DSN environment variable with the DSN you retrieved.

Deployment | Probot

Is your feature request related to a problem? Please describe.
I'm using actions and it assigned reviewers randomly each time the PR is updated with a new change, eventually adding too many people or everyone on my list.

Describe the solution you'd like
I'd like it to use some deterministic way of picking reviewers that is associated with something like a PR ID, so it will not assign more, different people with each push to the PR.

Describe alternatives you've considered
I haven't looked, but if PR ID is not a thing, maybe some other PR metadata, or branch name could be used.

I can look into implementing this and look forward to hearing if you like the idea and would accept a PR.

Is your feature request related to a problem? Please describe.
It'd be great to sequentially go through the reviewers list when assigning so that we don't tap an engineer multiple times in a row.

Describe the solution you'd like
I'd like assignment to be configurable to use a sequential rotation instead of random rotation.

I'd like to know if auto-assign is compatible with shared configs as specified here:
https://probot.github.io/docs/best-practices/#store-configuration-in-the-repository

I've tested it and it doesn't seem to work.

In https://github.blog/2019-02-14-introducing-draft-pull-requests/, github introduced draft PRs. Those PRs are not meant to be reviewed, yet. So the auto-assign bot should

• ignore draft PRs when they are created
• auto-assign when a draft PR is marked as ready

Is your feature request related to a problem? Please describe.
In my repository only CodeOwners can aprove a PR, but the code owner cannot aprove its own PR.

I've seen today that the bot can assign the PR to the same person who opened it. Example below:

Describe the solution you'd like
A boolean property to ignore the username of the person who opened the PR when assigning a reviewer.

Additional context

1. The person who opened the PR is a CodeOwner also, but can't approve his own PR.

Is your feature request related to a problem? Please describe.
We want to use this bot in our repo so that a PR can be auto assigned if not yet. But using this bot, we will auto assign an additional person even when it's already assigned.

Describe the solution you'd like
A bool to say if we need auto-assign to work when the PR is already assigned.

Describe the bug
missing "numberOfReviewers" in auto_assign.yml should add all reviewers

To Reproduce
Steps to reproduce the behavior:

1. have .github/auto_assign.yml with no "numberOfReviewers" key, in default branch
2. create pull request

Expected behavior
missing "numberOfReviewers" in auto_assign.yml should add all reviewers
according to README, default: 0

Additional context

Is your feature request related to a problem? Please describe.

Some of the reviews are frustrated when they are assigned but they're not responsible for the PR. They're just reviewers.

Describe the solution you'd like

I'd like to be able to have a separate assignees list.

Describe alternatives you've considered

I can remove the unwanted assignees from the reviewers list, but then they'd not get reviews, either.

Is your feature request related to a problem? Please describe.
We use a bot to update dependencies in our repositories, and our use of auto-assign would be limited to the PRs that this bot opens.

Describe the solution you'd like
A setting to add a list of PR labels. The dependency bot mentioned above can be made to auto-assign a label to its PRs (e.g. dependency) and auto-assign should then ignore any opened PR that does not include this label

Describe alternatives you've considered
In line with the already existing keyword blacklist setting, it might be simpler to add a keyword whitelist rather than implementing a way to read labels.

Additional context
Add any other context or screenshots about the feature request here.