-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include option to ignore PR activity #435
Comments
I want something similar but I want push event to be counted, but not the comments. So, a stale PR will not be stale anymore when author updates the code, but it will still be stale if something comments on it or move the milestone. Case study: astropy/astropy#9856 -- The last push was in Jan 2020, well over the stale limit. But we moved the milestone because our workflow is to attach milestones to all PRs. But
Should I open a new issue? p.s. I see that someone else attempted #390 but I don't think that would help me. I specifically want a PR to un-stale only on push (not supported) or if maintainer manually applies a special label (supported) and nothing else. |
Idea: Perhaps let users define their own triggers by passing in the param as a list. That way, each user can customize as they see fit without having to keep adding new options. Kinda like how Action handles event triggers for |
Any update on this? |
I can provide a PR if you want |
The PR is ready. |
@C0ZEN Thanks for putting together the PR. In our scenario PRs get autoupdated when a commit gets merged to the default branch so we want to be able to make the PRs stale purely based on the time they were created. Bonus option would be supporting a label so the action ignore them. |
@peimanja the new options support this because it uses the creation date instead of the update date to calculate the stale days.
You wish to be able to ignore commits before the stale or after the stale? |
Not my particular need, no. Please see #435 (comment) , thanks! Or should I open a separate issue? |
@pllim since this PR is only altering the workflow before the stale occur, yes based on your comment it would be wise to open a dedicated feature request. For the milestone case, it's something that doesn't exist at all yet and I think should be in a separated feature request. |
Doesn't exist in what way; can you please clarify? If there is no way to remove stale when milestone is changed, that is what I want anyway. But if there is no way to exclude milestone from removing stale, then it is not what I want. |
The only options right now involving milestones is to avoid staling if there is any milestone set or if there is specific(s) milestone(s). |
@C0ZEN So after a PR labeled as stale I want to be able to add a label to the PR so it does not get closed by this action and be ignored. I guess |
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false
@peimanja sadly nope, it's only to avoid staling, not to avoid closing. |
@C0ZEN That's fine. I guess in our stale message we can let users know that they have to remove the stale label and add another label so that PR/Issue being ignored by this action |
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false
@peimanja EDIT: sorry it's not when stale but rather when unstale. |
@peimanja ping because false hopes, sorry! See the edit |
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false
* feat(options): add new options to avoid stale based on comments Helping to close #441, #470, #435? Closes #390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false * style(readme): fix table syntax due to rebase * docs(readme): add permissions only for the new options
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
up |
@C0ZEN just checking to see how things are going with your PR, anything is blocking that? 😃 |
Helping to close actions#441, actions#470, actions#435? Closes actions#390 due to no activity BREAKING CHANGES: the options related to remove-stale-when-updated will only check the updates, not the comment. It is only impactint the configurations using the value at false
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
up |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
up |
Background
We currently use github actions on one of our gitops repos to autoupdate PRs with the latest main branch. Because of this PRs are updated frequently and considered to have a high amount of activity.
We wanted to also use github actions (actions/stale) to close PRs that had been open for several days. Currently the following is supported by action/stale:
This works as expected marking any PR as stale (that has not had any activity for 5 days) and closing it 3 days later if still labeled stale.
This however falls slightly short of our use case. For our use case we would like the option to ignore PR activity and mark the PR as stale if it has been open for 5 days (activity or no activity).
Request
Add a flag option such as
ignore-pr-activity
that ignores PR activity if set to true and simply tracks the time from when the PR was open.example:
The text was updated successfully, but these errors were encountered: