Allow filtering of PRs by review status or other criteria #1143
Labels
feature request
New feature or request to improve the current logic
Comments
gtjoseph
added
feature request
gtjoseph
added a commit
to asterisk/github-actions-stale
that referenced
this issue
Mar 14, 2024
Currently all open issues for context.repo.owner and context.repo.repo are retrieved using a simple call to client.rest.issues.listForRepo(); If we wanted to add other critera to determine staleness, like only considering PRs with a review state of "changes_requested", we'd have to make additional rest calls to get the reviews for each PR. This is fine but it only solves the issue for review state. Instead, this PR introduces a new action parameter named `only-matching-filter` which takes one or more standard GitHub Issue and Pull Request search strings. So instead of retrieving all open issues and PRs, you can limit the set to operate on by any criteria that GitHub supports. In the process, it opens up the ability to expand the set to include an entire organization or owner instead of just one repo. Example: Retrieve all open PRs for organization "myorg" that are in review state "changes_requested": `only-matching-filter: 'org:myorg is:pr is:open review:changes_requested'` Once that set is retrieved, all the other label, milestone, assignee, date, etc. filters are applied as usual. Although GitHub only allows boolean search critera in a Code search, you an get around that somewhat by specifying multiple search strings separated by ` || `. Example: Retrieve all open PRs for organization "myorg" that are in review state "changes_requested" or that have the label `submitter-action-required` assigned: (split onto two lines for clarity) ``` only-matching-filter: 'org:myorg is:pr is:open review:changes_requested || org:myorg is:pr is:open label:submitter-action-required' ``` Again, once that set is retrieved and duplicates filtered out, all the other label, milestone, assignee, date, etc. filters are applied as usual. If there aren't any `owner`, `org`, `user` or `repo` search terms in the filters, the search is automatically scoped to the context owner and repo. This prevents accidental global searches. `is:open` is also added if not already present. Resolves: actions#1143
|
Hello @gtjoseph |
|
@HarithaVattikuti Actually I have a PR coming that adds the ability to retrieve issues and PRs using a search string and client.rest.search.issuesAndPullRequests instead of blanket retrieving all open issues and PRs from the owner/repo using client.rest.issues.listForRepo. I'm just testing it now. |
gtjoseph
added a commit
to asterisk/github-actions-stale
that referenced
this issue
Mar 14, 2024
Currently all open issues for context.repo.owner and context.repo.repo are retrieved using a simple call to client.rest.issues.listForRepo(); If we wanted to add other critera to determine staleness, like only considering PRs with a review state of "changes_requested", we'd have to make additional rest calls to get the reviews for each PR. This is fine but it only solves the issue for review state. Instead, this PR introduces a new action parameter named `only-matching-filter` which takes one or more standard GitHub Issue and Pull Request search strings. So instead of retrieving all open issues and PRs, you can limit the set to operate on by any criteria that GitHub supports. In the process, it opens up the ability to expand the set to include an entire organization or owner instead of just one repo. Example: Retrieve all open PRs for organization "myorg" that are in review state "changes_requested": `only-matching-filter: 'org:myorg is:pr is:open review:changes_requested'` Once that set is retrieved, all the other label, milestone, assignee, date, etc. filters are applied as usual. Although GitHub only allows boolean search critera in a Code search, you an get around that somewhat by specifying multiple search strings separated by ` || `. Example: Retrieve all open PRs for organization "myorg" that are in review state "changes_requested" or that have the label `submitter-action-required` assigned: (split onto two lines for clarity) ``` only-matching-filter: 'org:myorg is:pr is:open review:changes_requested || org:myorg is:pr is:open label:submitter-action-required' ``` Again, once that set is retrieved and duplicates filtered out, all the other label, milestone, assignee, date, etc. filters are applied as usual. If there aren't any `owner`, `org`, `user` or `repo` search terms in the filters, the search is automatically scoped to the context owner and repo. This prevents accidental global searches. `is:open` is also added if not already present. Resolves: actions#1143
gtjoseph
added a commit
to asterisk/github-actions-stale
that referenced
this issue
Mar 15, 2024
Currently all open issues for context.repo.owner and context.repo.repo are retrieved using a simple call to client.rest.issues.listForRepo(); If we wanted to add other critera to determine staleness, like only considering PRs with a review state of "changes_requested", we'd have to make additional rest calls to get the reviews for each PR. This is fine but it only solves the issue for review state. Instead, this PR introduces a new action parameter named `only-matching-filter` which takes one or more standard GitHub Issue and Pull Request search strings. So instead of retrieving all open issues and PRs, you can limit the set to operate on by any criteria that GitHub supports. In the process, it opens up the ability to expand the set to include an entire organization or owner instead of just one repo. Example: Retrieve all open PRs for organization "myorg" that are in review state "changes_requested": `only-matching-filter: 'org:myorg is:pr is:open review:changes_requested'` Once that set is retrieved, all the other label, milestone, assignee, date, etc. filters are applied as usual. Although GitHub only allows boolean search critera in a Code search, you an get around that somewhat by specifying multiple search strings separated by ` || `. Example: Retrieve all open PRs for organization "myorg" that are in review state "changes_requested" or that have the label `submitter-action-required` assigned: (split onto two lines for clarity) ``` only-matching-filter: 'org:myorg is:pr is:open review:changes_requested || org:myorg is:pr is:open label:submitter-action-required' ``` Again, once that set is retrieved and duplicates filtered out, all the other label, milestone, assignee, date, etc. filters are applied as usual. If there aren't any `owner`, `org`, `user` or `repo` search terms in the filters, the search is automatically scoped to the context owner and repo. This prevents accidental global searches. `is:open` is also added if not already present. Resolves: actions#1143
gtjoseph
added a commit
to asterisk/github-actions-stale
that referenced
this issue
Mar 19, 2024
_Context:_ Normally, all open issues/PRs in the repository that's running this action are retrieved then all the label, assignee, milestone, etc. criteria you provide to the action are applied. Unfortunately, this limits the action to only those issues and PRs in this repository. It also prevents operating on only a subset of issues or PRs that can't be filtered by the existing action criteria. A good example of this are PRs that are in a `review:changes_requested` state. While additional filtering criteria could be added to the action, it would result in additional callbacks to GitHub which could trigger rate-limits to be applied. _Purpose:_ This option is an array of one or more standard [GitHub Issues and Pull Requests search queries] (https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests) which will be used to retrieve the set of issues/PRs to test and take action on. These queries will be used in place of the default retrieval of all open issues and PRs for the context's owner/repo. It can be used to expand or limit the set of issues and PRs operated on beyond what is retuned by the standard query. When the retrieval is complete, all the other label, assignee, milestone, etc. criteria will be applied. You may also use this option to improve performance when you have a large number of open issues or PRs but only a small subset might be eligible for action. For instance, let's say you have 1000 open issues in your repository but only those with label `auto-closable` should ever be automatically marked as stale or closed. By default, this action would retrieve all 1000 issues _and all open PRs_ and iterate over them looking for the label you specified in the `only-issues-label` parameter. If you use the `only-matching-filter` parameter with `repo:myorg/myrepo is:issue label:auto-closable` this would limit the download to just those issues you _know_ should have further criteria applied. _Syntax:_ ``` only-matching-filter: [ "<query_string>", ... ] ``` Or if there's only one query string... ``` only-matching-filter: '<query_string>' ``` _Examples:_ To operate only on the open PRs in your organization that have a review state of `changes_requested`: ``` only-matching-filter: 'org:myorg is:pr is:open review:changes_requested' ``` Since there's only one query specified, you can omit the array syntax and just specify the string directly. GitHub only allows boolean logic and grouping in a Code Searches not in Issues and Pull Requests searches so there's no way to do an "OR" operation but you can get around this to a limited degree by specifying multiple search queries in the form of a string array. Each query is run separately and the results are accumulated and duplicates removed before any further processing is done. To retrieve all of the open PRs in your organization that have a review state of `changes_requested` or a label named `submitter-action-required`, you'd use: ``` only-matching-filter: '[ "org:myorg is:pr is:open review:changes_requested", "org:myorg is:pr is:open label:submitter-action-required" ]' ``` _Notes:_ * Each query is checked to ensure it contains an `owner:`, `org:`, `user:` or `repo:` search term. If it doesn't, the search will automatically be scoped to the owner and repository in the context to prevent accidental global searches. If the request doesn't already contain an `is:open` search term, it will automatically be added as well. * If using the array form, the value of this parameter MUST be valid JSON which means using double quotes around each query string, not single quotes. Default value: '[]' Resolves: actions#1143
gtjoseph
changed the title
gtjoseph
added a commit
to asterisk/github-actions-stale
that referenced
this issue
Mar 20, 2024
_Context:_ Normally, all open issues/PRs in the repository that's running this action are retrieved then all the label, assignee, milestone, etc. criteria you provide to the action are applied. Unfortunately, this limits the action to only those issues and PRs in this repository. It also prevents operating on only a subset of issues or PRs that can't be filtered by the existing action criteria. A good example of this are PRs that are in a `review:changes_requested` state. While additional filtering criteria could be added to the action, it would result in additional callbacks to GitHub which could trigger rate-limits to be applied. _Purpose:_ This option is an array of one or more standard [GitHub Issues and Pull Requests search queries] (https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests) which will be used to retrieve the set of issues/PRs to test and take action on. These queries will be used in place of the default retrieval of all open issues and PRs for the context's owner/repo. It can be used to expand or limit the set of issues and PRs operated on beyond what is retuned by the standard query. When the retrieval is complete, all the other label, assignee, milestone, etc. criteria will be applied. You may also use this option to improve performance when you have a large number of open issues or PRs but only a small subset might be eligible for action. For instance, let's say you have 1000 open issues in your repository but only those with label `auto-closable` should ever be automatically marked as stale or closed. By default, this action would retrieve all 1000 issues _and all open PRs_ and iterate over them looking for the label you specified in the `only-issues-label` parameter. If you use the `only-matching-filter` parameter with `repo:myorg/myrepo is:issue label:auto-closable` this would limit the download to just those issues you _know_ should have further criteria applied. _Syntax:_ ``` only-matching-filter: [ "<query_string>", ... ] ``` Or if there's only one query string... ``` only-matching-filter: '<query_string>' ``` _Examples:_ To operate only on the open PRs in your organization that have a review state of `changes_requested`: ``` only-matching-filter: 'org:myorg is:pr is:open review:changes_requested' ``` Since there's only one query specified, you can omit the array syntax and just specify the string directly. GitHub only allows boolean logic and grouping in a Code Searches not in Issues and Pull Requests searches so there's no way to do an "OR" operation but you can get around this to a limited degree by specifying multiple search queries in the form of a string array. Each query is run separately and the results are accumulated and duplicates removed before any further processing is done. To retrieve all of the open PRs in your organization that have a review state of `changes_requested` or a label named `submitter-action-required`, you'd use: ``` only-matching-filter: '[ "org:myorg is:pr is:open review:changes_requested", "org:myorg is:pr is:open label:submitter-action-required" ]' ``` _Notes:_ * Each query is checked to ensure it contains an `owner:`, `org:`, `user:` or `repo:` search term. If it doesn't, the search will automatically be scoped to the owner and repository in the context to prevent accidental global searches. If the request doesn't already contain an `is:open` search term, it will automatically be added as well. * If using the array form, the value of this parameter MUST be valid JSON which means using double quotes around each query string, not single quotes. Default value: '[]' Resolves: actions#1143
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description:
Allow filtering of PRs by review status
Justification:
If a PR is waiting for us to review it, we'll get to it eventually so we don't want it marked stale or auto-closed. However, we DO want the process applied to PRs where the PR submitter hasn't responded to requests for changes in a certain amount of time (
review:changes_requested). Sure, we could manually add labels to the PRs to make them eligible or exempt from expiration but that defeats the purpose of the action. We could also write our own "pre-action" that automatically adds or removes labels based on review state but if we're going to do that, we might as well just do the expiration stuff ourselves as well.I'm wondering... maybe a filter by generic search string would be better since you could call the REST
/search/issuesendpoint with it. Actually this is what the submitted PR doesAre you willing to submit a PR?
Yes! Sumitted.
The text was updated successfully, but these errors were encountered: