dkhmelenko / autoapproval

The bot for approving pull requests

autoapproval

A GitHub App built with Probot for approving pull requests automatically

Setup

# Install dependencies
npm install

# Run typescript
npm run build

# Run the bot
npm start

# Run tests, don't forget to run `npm run build` beforehand
npm run test

This app requires Write code permissions in order not to have issues with approving PRs.

Repository administrators can require that all pull requests receive a specific number of approving reviews from people with write or admin permissions in the repository or from a designated code owner before they're merged into a protected branch.

...

You won't be able to merge your pull request until the required number of reviewers with write or admin permissions in the repository approve your pull request's changes in their review.

More about it can be found on Github Help.

Configure GitHub Action

This application runs on GitHub Actions. Create new file in your directory .github/workflows/autoapproval.yml and add the following configuration.

on:
  pull_request:
    types: [opened, reopened, labeled, edited]
  pull_request_review:
    types: [dismissed]
    
permissions:
  contents: read
  pull-requests: write
  
jobs:
  autoapproval:
    runs-on: ubuntu-latest
    name: Autoapproval
    steps:
      - uses: dkhmelenko/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Configuration

In order to use the bot, the config file should be provided. Config file should be defined in your repository. Config file is the yml file with the path .github/autoapproval.yml. The file should have at least 3 mandatory entries: from_owner, required_labels and apply_labels.

---

from_owner

mandatory

Defines the list of users, whos pull requests should be approved automatically. For example:

from_owner:
  - dkhmelenko
  - quongeri

Assign an empty array if you want to approve PRs from any user (example: from_owner: []).

---

required_labels

mandatory

Defines the list of labels on PR, which should be present for approving PR automatically. For example:

required_labels:
  - ready

Assign an empty array if you want to approve PRs without any label (example: required_labels: []).

---

required_labels_mode

Defines the behavior how required_labels should be treated. If nothing specified, then all labels from required_label are mandatory. If the value set to one_of, then it's enough to have only of the required_labels to get approval.

---

blacklisted_labels

Defines the list of labels on PR, which will prevent the PR from being automatically approved. For example:

blacklisted_labels:
  - wip

Assign an empty array if you do not want to blacklist any labels.

---

apply_labels

mandatory

Defines the list of labels on PR, which should be added once PR was approved automatically. For example:

apply_labels:
  - merge

Assign an empty array if no labels should be applied to PRs (example: apply_labels: []).

NOTES:

1. If label doesn't exist, it will not be created. In order to apply the label after approving PR automatically, you need to define the label beforehand.
2. If PR already contains a review from this bot, new approval will not happen. Except the case when review was dismissed.

---

auto_merge_labels / auto_squash_merge_labels / auto_rebase_merge_labels

Defines labels for which the bot should enable auto merging for the pull request. This will automatically merge the PR after approving it when all checks passed.

The following example with merge PR with the method "Merge" on GitHub:

auto_merge_labels:
  - auto-merge

You can also use "Squash & Merge" as merge method for a given list of labels:

auto_squash_merge_labels:
  - auto-squash-merge

The same is true for "Rebase & Merge":

auto_rebase_merge_labels:
  - auto-rebase-merge

NOTES:

• the Allow auto-merge setting must be enabled for the repository.
• it is enough to use only one of the options: auto_merge_labels, auto_squash_merge_labels or auto_rebase_merge_labels
• the repository should have enabled the merge method

Releasing

To release new version of the app, the following steps are required:

1. compile Node.js module into a single file by running the following command

ncc build index.js --license licenses.txt

2. tag new release and push tags

git tag -a -m "New action release" v1.1
git push --tags

Contributing

If you have suggestions for how autoapproval could be improved, or want to report a bug, open an issue! We'd love all and any contributions.

For more, check out the Contributing Guide.

License

ISC © 2018 Dmytro Khmelenko

autoapproval's Issues

what if the PR merge require 2 approvers?

any configuration can satisfy this requirement?

Service down?

Hey

Thanks for this cool app!
It looks like it stopped responding a couple of day ago.

Skip draft PRs

How to skip approval for draft PRs?

Setting up the GitHub App Bot

I see you made a GitHub App out of this bot 👍

However, after adding the GitHub App to my organization and repository, setting up with a .github/autoapproval.yml file (see below), nothing happens...
FYI I'm trying to set up autoapproval for dependabot PRs, related to this issue.

Any clue?

My .github/autoapproval.yml:

from_owner:
  - dependabot-preview
required_labels:
  - dependencies
apply_labels:
  - autoapproved

Dealing with rebased branches

If PR already contains all labels from apply_labels config, it will not be approved assuming that it was already approved.

Because of this behaviour, rebasing a branch results in the branch not being approved anymore, while still having the label.

Would you accept a pull request that changes this?

autoapprove a second time the same pull request

Hi,

I am using autoapproval to approve pull requests generated by Renovate (https://github.com/renovatebot/renovate).

My problem is when a pull request was approved once and another changes is then added to the branch it requires another approval and autoapproval doesnt seem to be able to do that.

Does autoapproval can approval the same pull request several times or not ?

Thanks

Remove "Write access to code" permission

I see your GitHub app requires Write access to code. Is this mandatory?
Since you are "only" approving pull requests, I would tend think it's not 🤔 .

Self hosted app is not showing up

Hi! I have tried to host the app in my own server. The hosting worked in general. When a PR is created the webhook is triggerred and I get a 200 response but the app itself does not show up in the repository. Could you please tell me if I am missing anything?

Config file:

required_labels: 
  - []
from_owner:
  - []
blacklisted_labels:
  - do-not-merge
apply_labels:
  - auto-merge

Approved comment spammed on PR

Just finished setting this up using your GitHub App for my project ass. Opened a test PR and got a ton of comments...

My Yaml file is as follows:

from_owner:
  - tycrek
required_labels:
  - tycrek
apply_labels: []

The PR in question: tycrek/ass#81

As you can see in the PR, it spammed a ton of "Approved" comments which I don't think is supposed to happen. Any idea what would have caused this?

Deploy application to Fly

The app has to work as before on Heroku.

Fly offers free plan for that https://fly.io/

Multiple approved comments depending on the number of labels.

Hello.
I have a problem with multiple approved comments from your bot.

Problem

I got multiple approved comments from autoapproval bot depending on the number of labels.

If I put three labels when I create a pull request, I got three approved comments.
If I put five labels when I create a pull request, I got five approved comments.

After I create a pull request, the change of labels does not trigger sending approved comments.

autoapproval.yml

This is my autoapproval.yml.

from_owner:
  - wadakatu
  - dependabot[bot]
required_labels: []
apply_labels: []

Evidence

wadakatu/Koyolympus#129
wadakatu/Koyolympus#130
wadakatu/Koyolympus#131

Could you tell me this behavior is as you expected or not?
If you need more information, please let me know.
Thank you.

Error: Cannot read properties of null (reading 'blacklisted_labels')

I'm having some trouble integrating this action. There seems to be issues around reading the config file which I've copied verbatim from the example and placed at .github/autoapproval.yml. I think we need to provide the additional contents: read permission so that it can read the config.

permissions:
  contents: read
  pull-requests: write

However, after doing that, I still seem to be runninig into issues:

Run dkhmelenko/[email protected]
Repo: myorg/reponame
{ name: 'event', id: '3678729916' }
PR: https://github.com/myorg/reponame/pull/1455
{ name: 'event', id: '3678729916' }
Action: opened
{ name: 'event', id: '3678729916' }
Loaded config
{ name: 'event', id: '3678729916' }
Error: Cannot read properties of null (reading 'blacklisted_labels')
{
  name: 'event',
  id: '3678729916',
  err: {
    type: 'TypeError',
    message: "Cannot read properties of null (reading 'blacklisted_labels')",
    stack: "TypeError: Cannot read properties of null (reading 'blacklisted_labels')\n" +
      '    at /home/runner/work/_actions/dkhmelenko/autoapproval/v1.0/dist/index.js:128784:32\n' +
      '    at step (/home/runner/work/_actions/dkhmelenko/autoapproval/v1.0/dist/index.js:128751:[23](https://github.com/etsy/airflow/actions/runs/3678729916/jobs/6222480786#step:2:24))\n' +
      '    at Object.next (/home/runner/work/_actions/dkhmelenko/autoapproval/v1.0/dist/index.js:1[28](https://github.com/etsy/airflow/actions/runs/3678729916/jobs/6222480786#step:2:29)7[32](https://github.com/etsy/airflow/actions/runs/3678729916/jobs/6222480786#step:2:33):53)\n' +
      '    at fulfilled (/home/runner/work/_actions/dkhmelenko/autoapproval/v1.0/dist/index.js:128723:58)',

Any idea what the issue might be?

Add tests

The implementation should have tests in order to bring more confidence in the source code.

Check PR approval status through GitHub API

Instead of using the labels to determine if the PR requires an approval review, we could use the Github API to check if the PR has a non-dismissed review from autoapprove or not. This would make re-running the approval easier.

developer.github.com/v3/pulls/reviews/#list-reviews-on-a-pull-request

Automerge not occurring as expected

Not sure if this is a bug or PEBCAK yet, but I would expect [this PR])(TheKevJames/challenges#128) to be automerged based on my config and the actions definition.

Relevant repo settings:

• "Allow auto-merge" is enabled
• "Allow squash merging" is enabled
• Branch protection has "Require status checks to pass before merging" and "Require branches to be up to date before merging"

Expected workflow:

1. pre-commit-ci[bot] opens the PR
2. autoapproval triggers on the pull_request.opened trigger
3. autoapproval approves the PR and adds the automerge label
4. autoapproval triggers on the pull_request.labeled trigger
5. autoapproval sees the automerge labels and does a squash merge once required tests pass

It seems like either step (4) or (5) is not triggering (seems to be (4) based on the Actions history). Am I doing something wrong here?