Feature Request

Describe the solution you'd like
Currently using github-changelog-generator to generate the CHANGELOG. This can be automated with GitHub actions such as https://github.com/marketplace/actions/generate-changelog

Describe alternatives you've considered
Need to research alternatives

Teachability, Documentation, Adoption, Migration Strategy
See doco on https://github.com/github-changelog-generator/github-changelog-generator

Feature Request

Is your feature request related to a problem? Please describe.
In static blog generators it is common to use front matter to define the article author or owner. These people should be assigned as reviewers.

Describe the solution you'd like
Provide a feature which can enable the automatic assignment of reviewers from a yaml key.

Describe alternatives you've considered
None seem to be available

Currently the review required label gets added when PR is created/update and criteria is met. When reviews are complete though it isnt removed and this then blocks auto merge

Bug Report

Current Behavior
When editing through GitHub UI and providing multiple commits to a PR the initial instructions on comment automation are being submitted multiple times.

To Reproduce
Steps to reproduce the behavior:

1. Edit a file via GitHub UI, commit to a new branch, and create PR
2. Edit another file in the same branch and commit
3. Edit another file in the same branch and commit
4. You will see multiple comment automation messages. See screen shot

Expected behavior/code
The instructions should only be sent on PR open

GitHub Action Configuration (.yml, etc)

N/A

Environment

• version(s): Dev branch (based on v0.1)

Possible Solution
Working on it

Additional context/Screenshots
Example

Feature Request

Is your feature request related to a problem? Please describe.
Have found that when some workflows include long-running additional checks (e.g. builds etc) we can run into a Race Condition between the completion of Pr Helper and that other check/workflow.
For example, assume that all conditions are met and Pr Helper should proceed with merging the PR. However, there is an additional check running a build of the application that takes 10 mins to complete, that process would then block the merge from being complete. It would also then mean Pr Helper is not run again until further actions are taken, and such actions could trigger the same race condition.

Describe the solution you'd like
GitHub has provided support for the WorkFlow_Run event as a trigger. This will mean we can add a condition that will re-trigger the PR Helper at the completion of that long-running workflow/task.
https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run

Describe alternatives you've considered
None as GitHub has native support for this now

Teachability, Documentation, Adoption, Migration Strategy
TBA

Need to look at moving the configuration content so that it is leveraged from the master branch. Possible option is just move it to the workflow file

Bug Report

Current Behavior
Currently getting some errors following the deletion of the source branch

Additional context/Screenshots

Feature Request

Is your feature request related to a problem? Please describe.
Current solution introduces a blocker in the workflow when waiting on others to approve content changes to content you own

Describe the solution you'd like
When using the frontmatter reviewer assignment feature, and a content owner modifies their own content the workflow should not require that someone else reviews it. It should just pass through without any reviewer requirement.

When adding new files it should allow for specifying a default reviewer (in case the repo doesn't have CODEOWNERS configured)

When renaming a file, this workflow should be thought through. It should initially work the same as modifying files. Maybe in the future it needs to be a configurable setting.

Describe alternatives you've considered
Only alternative right now is to disable the minimum required reviews which affects everyone not only the content owners.

Teachability, Documentation, Adoption, Migration Strategy
TBA

Bug Report

Current Behavior
The current logic is that the following conditions need to be met

1. All requested reviews are provided and minimum review is disabled
2. All provided reviews are approved and (reviews greater or equal to minimum count required or minimum count disabled)
3. Approved reviews is greater or equal to minimum count required (if enabled)

This could cause unexpected merger in the case where there are requested changes but others have approved the change as this would pass check 3

To Reproduce
Steps to reproduce the behavior:

With minimum review count = 1

1. Create a PR
2. As a reviewer request changes via a review
3. Another reviewer approve the change
4. Auto merge will happen

Expected behavior/code
We should expect that while there is a rejected review it does not process the auto merge

GitHub Action Configuration (.yml, etc)

jobs:
  prhelper_job:
    runs-on: ubuntu-latest
    steps:
    - name: Run PR Helper
      id: runprhelper
      uses: Matticusau/[email protected]
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        enable-prmerge-automation: true
        enable-prcomment-automation: true
        enable-prlabel-automation: true
        enable-welcomemessage: true
        welcome-message: "Thanks for opening an issue! Make sure you've followed CONTRIBUTING.md."
        prmerge-requireallchecks: true
        prmerge-requirereviewcount: 1
        permerge-method: 'merge'

Feature Request

Is your feature request related to a problem? Please describe.
Currently the auto-merge is based on if the PR is not dirty or blocked

Describe the solution you'd like
Auto merge should include additional filters/rules

• File path Glob to control which allow auto merge (e.g. only within /docs would qualify)
• Limit number of files changed
• Limit the code coverage changed
  etc

Describe alternatives you've considered
Need to research

Teachability, Documentation, Adoption, Migration Strategy
TBA

Bug Report

Current Behavior
The PR Helper is configured to add reviewers based on specific YAML front-matter. This can also include a configuration lookup file. The issue is that the person being added needs to be a collaborator on the repository. In the event that you remove that persons access you will receive an error and the PR Helper will fail to complete, thus blocking the PR from being merged and requiring manual intervention.

In the event that the addition of the reviewer fails for that reason then it should just be logged and not block the rest of the processing.

To Reproduce
Steps to reproduce the behavior:

1. Grant someone access to the repo
2. Set them as a MD file owner in appropriate YAML front-matter
3. Configure PR Helper as appropriate
4. Create a PR
5. See error

Expected behavior/code
In the event that the addition of the reviewer fails for that reason then it should just be logged and not block the rest of the processing.

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

Text based error

Error: Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the ABC/XYZ repository.

PR events that are kicked off by members who don't have permissions to merge a PR will result in a blocked state. Running on schedule should work around this permissions issue.

Bug Report

Current Behavior
After enabling the frontmatter reviewer assignment and modifying a file that has no frontmatter it generates the following error

To Reproduce
Steps to reproduce the behavior:

1. Create a PR that modifies files with no frontmatter
2. See error

Expected behavior/code
Should not generate an error for files without frontmatter and should not assign a reviewer

GitHub Action Configuration (.yml, etc)

with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        enable-prmerge-automation: true
        enable-prcomment-automation: true
        enable-prlabel-automation: true
        enable-prreviewer-frontmatter: true
        enable-welcomemessage: true
        welcome-message: "Thanks for opening an issue! Make sure you've followed CONTRIBUTING.md."
        prmerge-requireallchecks: true
        prmerge-requirereviewcount: -1
        prmerge-pathcheck: true
        prmerge-method: 'merge'
        prmerge-deletebranch: true
        prmerge-deletebranch-config: '{"deny":["dev", "main"]}'
        prmerge-allowpaths: '{"any":["docs/**","assets/**"]}'
        prreviewer-authorkey: 'author'
        prreviewer-githubuserfromauthorfile: true
        prreviewer-authorfilepath: '_data/authors.yaml'
        prlabel-default: 'pr-onhold'
        prlabel-ready: 'pr-ready'
        prlabel-onhold: 'pr-onhold'
        prlabel-reviewrequired: 'review-required'
        prlabel-automerge: 'auto-merge'

Possible Solution
TBA

Additional context/Screenshots

I might be missing something — this implementation looks like it only handles labeling and comments. Does it also respect a codeowners doc and handle assignments?

I found this https://github.com/technote-space/github-action-pr-helper which looks similar, and includes an assign-author action too

Bug Report

Current Behavior
When a PR is raised from a Fork of a Repo the GitHub Action is not triggered. Once the PR is open and a comment is made then there is evidence that the action executes.

To Reproduce
Steps to reproduce the behavior:

1. For a repo which has this action configured
2. Create some changes and submit a PR to propose the changes back to the base repo
3. No action will be executed
4. Add a comment to the PR
5. The Action will be run as seen in the actions tab.

Expected behavior/code
Expecting the action to execute when opened from a fork of the repository

Additional context/Screenshots

Most relevant info seems to be in https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories

When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository.

There does some to be some history of this.
https://github.community/t/actions-not-working-correctly-for-forks/16649
https://github.community/t/run-a-github-action-on-pull-request-for-pr-opened-from-a-forked-repo/16054

Webhook may have some extra info we can use for say tracking other post create events and then checking if it is a fork and taking some additional actions: https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#pull_request

I think the current behavior I have witnessed may actually be related to private-vs-public repos. I believe this is supported in public repos but not in private repos/forks.

Again from https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull-request-events-for-forked-repositories

Note: Workflows do not run on private base repositories when you open a pull request from a forked repository.

Feature Request

Is your feature request related to a problem? Please describe.
Currently in Jekyll like blog sites it is not mandatory to specify a GitHub username as the article Author or similar front matter value. It is common to use a friendly name which is then mapped to further details in an author file.

Describe the solution you'd like
The solution should be to provide a path to a key:value YAML or JSON type file which is used to look up the GitHub username of the author. I prefer a YAML solution to match the configuration standard in GitHub Actions. I see two options:

1. Store a custom YAML file in the .github directory. This file could be in the format of

Author Name: githubusername
Author Name: githubusername

Or

Author Name:
  ghaccount: githubusername
Author Name:
  ghaccount: githubusername

2. [Preferred option] Support the use of the Jekyll Author file syntax. Similar to option 2 above. This could still be a path file in the .github directory or if it is a Jekyll blog then the _data/authors.yml. So adding an additional field to the author file for the GitHub UserName such as:

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

Describe alternatives you've considered
Haven't found any alternative GitHub Actions to provide this functionality.

Alternatively we do not provide this functionality and simply continue with the current functionality which requires the GitHub account in the pages front matter. Which is not ideal as it duplicates the data needing to be maintained on each page if that is not already part of your Jekyll site.

Teachability, Documentation, Adoption, Migration Strategy
TBD

Need to look into what could be done to support branch protection rules.

The config file should be pulled from the default branch or the target of the pr. Right now it comes from the current branch where the PR is created from

Bug Report

Current Behavior
Currently when the Add labels is triggered, regardless of if any changes are needed or not we are changing the array and posting to the API. This results in many unnecessary API calls and label changes.

To Reproduce
Steps to reproduce the behavior:

1. Configure the Github Action both ondemand and scheduled
2. Create a Pull Request
3. Add comments, reviews etc without triggering the merge
4. Watch the Action log but also the details of the PR will reflect unnecessary label changes

Expected behavior/code
No unnecessary API calls

Environment

• version(s): 1.3.2

Possible Solution
An additional check is needed to ensure that we only make changes if the label doesn't already exist

Change this

    addLabel(label : string) : void {
        if(label.length > 0) {
            this.labels.push(label);
            this.haschanges = true;
        }
    }

to this

    addLabel(label : string) : void {
        if(label.length > 0) {
            if (this.labels.indexOf(label) <= 0) {
                this.labels.push(label);
                this.haschanges = true;
            }
        }
    }

Additional context/Screenshots
N/A

Bug Report

Current Behavior
When commenting on an issue this seems to be causing a 'Not Found' error. Most likely on the get PR code.

To Reproduce
Steps to reproduce the behavior:

1. Create a new issue
2. Create a comment on the issue
3. See error in Actions run log

Expected behavior/code
Should not run on an Issue comment

Possible Solution
Webhooks for Issue and PR commenting are the same, we need to improve the code to handle this.

Additional context/Screenshots

Feature Request

Is your feature request related to a problem? Please describe.
In a busy Repo it can be that some PRs may become stale as the author or reviewer is not responding. We need an easy way to identify them through labels.

Describe the solution you'd like
Add a label to the PR when it is stale (inactive for X days).
Remove the label when updated.

Describe alternatives you've considered
None

Feature Request

Is your feature request related to a problem? Please describe.
There will be branch sprawl and require manual clean up once automatic merge is implemented

Describe the solution you'd like
To avoid the issue of manually cleaning up branches an option should be added to automatically delete the branch on merge. Should default to off in settings.

Describe alternatives you've considered
Might be other Actions already providing this functionality

Teachability, Documentation, Adoption, Migration Strategy
TBA

Bug Report

Current Behavior
The Action is returning an error when creating a new file.

Environment

• version(s): v1.2.2

Possible Solution
N/A

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

Should implement some issue templates. Check out these resources

• https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates
• https://github.com/stevemao/github-issue-templates
• https://github.com/devspace/awesome-github-templates

Bug Report

Current Behavior
Currently the auto merge workflow does not require that the auto merge qualifying label is set. That label is set during the workflow when it determines that the PR qualifies for auto merge or not.

To Reproduce
Steps to reproduce the behavior:

1. Configure the path check to exclude some files
2. Create a PR that modifies files that pass the path check and others that do not pass the check
3. Notice that the PR will not have the qualifies for auto merge label assigned, however review the log files and the workflow will continue to try and process the PR for merge

Expected behavior/code
Additional check should be performed before merging to make sure it does qualify for auto merge, not that it is just ready to merge

GitHub Action Configuration (.yml, etc)

with:
  enable-prmerge-automation: true
  prmerge-requireallchecks: true
  prmerge-requirereviewcount: 1
  prmerge-method: 'merge'
  prmerge-deletebranch: 'true'
  prmerge-deletebranch-config: ''
  prmerge-pathcheck: true
  prmerge-allowpaths: '{"any":["articles/**"]}'
  prlabel-default: 'pr-onhold'
  prlabel-ready: 'pr-ready'
  prlabel-onhold: 'pr-onhold'
  prlabel-reviewrequired: 'review-required'
  prlabel-automerge: 'qualifies-auto-merge'

Possible Solution
TBD

Additional context/Screenshots
Was discovered while investigating #27

The welcome message text should respect special characters. In this screen shot the new lines are not reflected when brought in from Yaml. When typed directly in typescript this comes through.

Question

Before you post:

• Have you read the readme?

What is your question?
How to enable auto-merge ?
Right now it only adds labels but does not merge PRs automatically

Background information
Describe the background of your question. Problems you are trying to solve, the reason for reaching out, etc.

Feature Request

Is your feature request related to a problem? Please describe.
It is now not possible to run this workflow from a fork

Describe the solution you'd like
Adding pull_request_target will resolve this

Describe alternatives you've considered
None.

Teachability, Documentation, Adoption, Migration Strategy
Full discussion on workaround can be found danilo-delbusso/pr-review-labeller#1

Bug Report

Current Behavior
Currently when you have multiple files modified by a Pull Request, which have different Reviewers assigned through CODEOWNERS. Or when you manually assign someone in addition to the CODEOWNERS then the Merge is still blocked until a CODEOWNER for each of the files modified approves the PR.

To Reproduce
Steps to reproduce the behavior:

1. Configure the CODEOWNERS with different owners for separate folders/files
2. Submit a PR that modifies at least 2 different files which has different CODEOWNERS assigned
3. 1 of the CODEOWNERS approves the PR
4. The workflow will attempt to process if configured with minimum of 1 reviewer but be blocked as it is waiting on approval

See the error lines in this log extract

2020-07-27T01:33:18.0038722Z PR #26 labels do not allow merge
2020-07-27T01:33:18.0038938Z Processing PR 23!
2020-07-27T01:33:18.2470786Z PR State: open
2020-07-27T01:33:18.2471053Z PR merged: false
2020-07-27T01:33:18.2471418Z PR mergeable: true
2020-07-27T01:33:18.2482199Z PR mergeable_state: blocked
2020-07-27T01:33:18.3891059Z readyToMergeLabel:true
2020-07-27T01:33:18.3891242Z NotReadyToMergeLabel:false
2020-07-27T01:33:18.5017715Z required checks have all succeeded
2020-07-27T01:33:18.6966817Z PR #23 is mergable based on reviews
2020-07-27T01:33:18.6967033Z PR #23 is mergable based on minimum required reviews
2020-07-27T01:33:18.6967193Z Merged PR #23
2020-07-27T01:33:19.2335596Z ##[error]Waiting on code owner review from octocat.
2020-07-27T01:33:19.2340613Z ##[error]Waiting on code owner review from octocat.
2020-07-27T01:33:19.2341323Z Error: Waiting on code owner review from octocat.
2020-07-27T01:33:19.2341603Z ##[error]Waiting on code owner review from octocat.
2020-07-27T01:33:19.2432269Z Uploading runner diagnostic logs
2020-07-27T01:33:19.2539568Z Completed runner diagnostic log upload
2020-07-27T01:33:19.2539697Z Cleaning up orphan processes

Expected behavior/code
The workflow should not attempt to proceed when this is occuring.

GitHub Action Configuration (.yml, etc)

with:
        repo-token: ${{ secrets.GHACTION_PAT }}
        enable-prmerge-automation: true
        enable-prcomment-automation: true
        enable-prlabel-automation: true
        enable-prreviewer-frontmatter: false
        enable-welcomemessage: true
        welcome-message: "Thanks for opening an issue! Make sure you've followed CONTRIBUTING.md."
        prmerge-requireallchecks: true
        prmerge-requirereviewcount: 1
        prmerge-method: 'merge'
        prmerge-deletebranch: 'true'
        prmerge-deletebranch-config: ''
        prmerge-pathcheck: true
        prmerge-allowpaths: '{"any":["articles/**"]}'
        prreviewer-authorkey: ''
        prlabel-default: 'pr-onhold'
        prlabel-ready: 'pr-ready'
        prlabel-onhold: 'pr-onhold'
        prlabel-reviewrequired: 'review-required'
        prlabel-automerge: 'qualifies-auto-merge'

Possible Solution
Need to investigate how much detail is provided via API to see if it is possible to check the CODEOWNER is pending. Need to factor groups into this as when a member of the group approves the group still remains but does not block. This relates to when there is a changed file which has not approvals yet.

Additional context/Screenshots
None

Feature Request

Is your feature request related to a problem? Please describe.
When relying on FrontMatter to determine the Author for review. If there is no author key in the FrontMatter we should require reviews or set a default reviewer?

Describe the solution you'd like
A default reviewer or block auto merge are possible options

Describe alternatives you've considered
Tweaking the review count required might work

Teachability, Documentation, Adoption, Migration Strategy
TBA

When adding a comment a Not Found error is occurring when trying to retrieve the PR details

Bug Report

Current Behavior
When renaming a file it will cause a Not Found error in the workflow

To Reproduce
Steps to reproduce the behavior:

1. Rename an existing file
2. Submit a PR
3. See error

Expected behavior/code
The workflow should detect the original file name and check that file for the owner

Environment

• version(s): v1.2.2

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

Bug Report

Current Behavior
When using front-matter reviewer requests, the logic may try and request a review from the person who raised the PR.

CODEOWNERs is not impacted by this as GitHub handles that internally.

To Reproduce
Steps to reproduce the behavior:

1. Add a file with frontmatter referencing your username as the owner (configure the appropriate settings for the key value)
2. Create a PR that edits that file
3. The workflow will fail as it tries to assign you as the reviewer
4. See error

Expected behavior/code
A check should be added to avoid adding the PR owner as the reviewer

Environment

• version(s): v1.2.1

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.