Is your feature request related to a problem? Please describe.
The current recommend setup is to run on a schedule. This can mean things get merged before they would get labeled if development is moving fast enough.

Describe the solution you'd like
Supporting workflow_run events means this workflow can be triggered when another workflow is triggered. So you would setup a pull request trigger workflow that this workflow would watch for. When the trigger runs (when a pull request is opened) this workflow would run. Basically triggered instead of scheduled

Describe alternatives you've considered
I've been trying everything under the sun to find a way to have pull request labeled on the spot.

Additional context
https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run

https://github.com/GhostWriters/DockSTARTer/runs/960569424?check_suite_focus=true

The priority command will label the issue with priority/some-priority based on your .github/labels.yaml file.

For example, if the labels.yaml file contains:

priority:
  - 'low'

Some things in prow are pretty straightforward to re-implement, but some is quite a bit of logic. A big feature that I'm interested in is determining which reviewers and approvers to select for a pull request when there can be multiple OWNERS files defined in a repository, and then ensuring that a PR isn't merged until approvers from all OWNERS files have given approval. So if a PR touches two directories, which have different approvers, both approvers would have to approve the PR before it is merged by our github action. (Correct me if I'm misunderstanding how prow works!)

The kuberentes/test-infra repository defines this logic and has functions that we could export, wrap and call from javascript. Alternatively we could port these functions to typescript.

Before I spent time doing any of that, I wanted to get a feel for what you would prefer? I'm down for implementing either solution.

It would be great if when doing a GitHub code review, if the reviewer used /lgtm or /approve in the summarizing review comment, that it was recognized by the github action. I think without that, it would be easy for people to do a review with those commands, and not realize that their command isn't being acted upon.

I'm going to look into what events we'd need to listen for to make this work.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The default strategy for merging pull requests when using /lgtm is a pull request merge. Some users might want to flexibility to control the merge strategy.

I took a stab at trying to implement this, but I have not worked with TypeScript, and could not easily.

Describe the solution you'd like
A clear and concise description of what you'd like to happen.
I would like to be able to choose the merge strategy when creating the action workflow for the LGTM cron job. Here is an example of what the action workflow could look like

name: "Merge on lgtm label"
on:
  schedule:
  - cron: "0 * * * *"

jobs:
  execute:
    runs-on: ubuntu-latest
    steps:
      - uses: jpmcb/prow-github-actions
        with:
          jobs: 'lgtm'
          merge-method: squash
          github-token: "${{ secrets.GITHUB_TOKEN }}"

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
In my use case we prefer to squash when merging a pull request. If we can't control this we would need to disable the /lgtm command

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

Based on your code here: https://github.com/jpmcb/prow-github-actions/blob/main/src/cronJobs/lgtm.ts#L115 there is an option in octokit/rest to set merge_method as documented here: https://octokit.github.io/rest.js/v18#pulls-merge

Is your feature request related to a problem? Please describe.
I want to specify exactly who can provide reviews and approve pull requests since there are a lot of people in the organization who do not qualify as reviewers and approvers.

Describe the solution you'd like
I'd be happy with any way to specify a named set of people or teams that can be reviewers and approvers. Either by reading the OWNERS file (like prow does), or something more simple like just passing the action a list of names in the workflow file. I realize the full logic of owners files is pretty complex, and I just care about having a bit more control than just org membership.

Describe alternatives you've considered
N/A

Additional context
I'm happy to submit a PR for this if this is a welcome feature.

Currently the path to the OWNERS file is hardcoded to the root of a single repository.

what I'd like
Allow the retrieval of the owners file to be configurable to specify a path or URL. (A URL would allow 1 owners file to apply to multiple repositories.)

why Operator Framework could use this
The Operator Framework is a federated project that could benefit from owners-file-based automation that is lighter weight than prow. We have multiple subprojects and subproject's OWNERS could be applied to multiple repositories.

stretch goal (separate issue?)
It would be nice to allow multiple owners files. For example operator-framework/community owners could be scraped from the owners files of multiple repositories. Seems like this could be done in 1 PR, but I'll create a separate issue if desired.

The milestone command is used to add a PR or issue to an existing milestone. Note that the milestone must already exist, prow-github-actions will not create a milestone with this command.

Is your feature request related to a problem? Please describe.
When I opened the repo, I expected the tool to work with new or edited comments.

Describe the solution you'd like
A clear and concise description of what you'd like to happen.

• README.md updated to reflect this change
• possible code changes to make this work?

Describe alternatives you've considered
N/A

Additional context
N/A

Comments can contain multiple commands and prow-github-actions attempts to parse all commands it finds in a single comment.

We are currently on version v2.1.1 of @actions/github which includes an older version of @octokit/rest. v17.0.0 had several major breaking changes (and features) that would be nice to be up to speed on.

As a developer of prow-github-actions
I want to use the latest version of @octokit/rest and it's APIs
So my experience contributing is improved
And to get the latest security bumps

The kind command will label the issue with kind/some-kind based on your .github/labels.yaml file.

For example, if the labels.yaml file contains:

kind:
  - 'cleanup'

The lock command will lock the issue or PR and prevent any further commenting. You may provide any of the three optional reasons: resolved | off-topic | too-heated.

Using the assign command, one can assign themselves or other users. The target user must be an org member, a repo collaborator, or have previously commented on the issue / PR.

Collaborators can remove labels using the remove command

The area command will label the issue with area/some-area based on your .github/labels.yaml file.

For example, if the labels.yaml file contains:

area:
  - 'bug'

Describe the bug
When putting a / command in a code segment, the bot should not follow the command.

/approve

To Reproduce
I just did! The bot should reply with an erroneous comment, see below :)

I did not label this with area. Lets see what happens.

The retitle command allows collaborators to easily rename issues and PRs.

Let's cut a v1.2.0 release.

This will have updates from Dependabot, NPM module updates, and feature adds by @carolynvs 👏🏼

As I was implementing OWNERS file support, I noticed that from the commenter's perspective it's not always clear when the command failed, and where to see what happened. Other github bots will usually reply back when it can't execute the command or tells you what it did on your behalf.

What if we had the bot post back if the commenter isn't authorized to run that command, or the result of what the action did (e.g. added a label)? I'm not sure if chattiness is a problem but it seems like this would help users quickly know how their command worked out.

carolynvs: /lgtm
prow: Cannot apply the lgtm label because @carolynvs is not in the reviewers role in the OWNERS file

carolynvs: /lgtm
prow: Added lgtm label

subsequent /lgtm commands won't print anything because the label is already applied

carolynvs: /lgtm cancel
prow: Removed lgtm label

carolynvs: /approve
prow: The pull request was approved by @carolynvs

Collaborators for a repo can use close and reopen to easily manage issues and PRs

Describe the bug
Tests seem to be broken in this repos GitHub actions. This has actually been a long standing problem I haven't had a ton of time to dive into. Let's see if we can get the tests to run in GitHub actions so that we have a good signal for contributors.

To Reproduce

Notice that tests aren't working in contributor PRs: #51
or in bot PRs: #50

Expected behavior
Tests to run successfully without error if tests are corrects

The lgtm label should be removed if a PR with that label gets a new commit. This way, intermittent / in work changes aren't being merged.

In this chunk, when checking the membership of the commenter:

try {
    if (context.payload.repository === undefined) {
      core.debug(`checkOrgMember error: context payload repository undefined`)
      return false
    }

    await octokit.orgs.checkMembership({
      org: context.payload.repository.owner.login,
      username: user
    })

    return true
  } catch (e) {
    return false
  }

We don't surface the error when it's thrown. This would be really useful information, especially since GitHub org and Auth stuff can be really really tricky.

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

• When run prow-actions, got this warning:
  Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: jpmcb/prow-github-actions

Describe the solution you'd like

• Without any warning

Describe alternatives you've considered

Additional context

The GitHub issue and bug templates could use an update. They're a bit wordy.

/assign @JDHulling

If you'd like to take a look and give an update to the copy, go ahead!

Is your feature request related to a problem? Please describe.
I'm a user from Jenkins-X, which extends chatops command from Prow. The command I like is meow. I have a proposal to add it as a command. ><)

This is just nice to have. If you think it's a waste. Feel free to close the issue. Otherwise, I can find the time to implement it.

Right now, the documentation lives in the docs/ folder as a bunch of markdown files.

It would be great if we could take advantage of GitHub pages and deploy some kind of actual documentation site that will be alittle easier for users to navigate. Especially as prow-github-actions grows, we'll need docs to grow as well.

Describe the bug

The action is frequently considered "Failed", from the action log:

To Reproduce
Steps to reproduce the behavior:

1. Run labeler on a project with many PRs (~ 146 in our case)

Expected behavior
Labeler action completes without error

Github repo
https://github.com/OpenMage/magento-lts/runs/1429450362?check_suite_focus=true

Logs

...
processing pr: 113
starting PR labeler page 6
Error: Error: error handling issue comment: Error: could not get PRs: HttpError: You have triggered an abuse detection mechanism. Please wait a few minutes before you try again.

Additional info
Perhaps the PRs can be filtered to only consider those that have changed in the last 4 hours?

✨ Feature ✨

We should build a system to do prow operations end to end on a test repo.

This would be obviously beneficial since it would create a way to determine if the API has changed, if new changes to the prow bot break the existing operations and functionaliy, etc.

As it stands today, we run unit tests, but nothing end to end on an actual GitHub repository.