Skip to content
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

Feat: Rotten Issues #1140

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

mviswanathsai
Copy link

@mviswanathsai mviswanathsai commented Mar 3, 2024

Description:
This PR aims to add functionality that lets the user keep an issue in an intermediate state between stale and closed: rotten. This enables the user to do Kubernetes-like (a very mild like) issue life-cycle management. This is done in Kubernetes using the traige-robot.

As per the changes in this PR, after an issue is created:

  1. Stays as is till a value specified by days-before-stale.
  2. If no update is done to the issue for this time period, it is then moved to a Stale state.
  3. The issue stays labelled as Stale till a time period specified by days-before-rotten.
  4. If no update is done to the issue within this time period, it is then moved to a Rotten state.
  5. It stays Rotten till a time period specified by days-before-close.
  6. If no update is done to the issue within this time frame, then it is closed.
  • At each of these stages, the labels can be any arbitrary string the user wants to use for their repository. It is by default, Stale and Rotten.
  • On an issue update, the labels added by the action can be removed, or not. That depends on how the user configures the action and it is no different from how the stale action functioned before this PR.
  • An issue can be closed without it ever needing to be rotten, in case the user prefers to use the stale action as it originally was. This PR defaults the rotten value to days-before-rotten: -1 i.e., does not rotten any issues and so does not disturb the flow of users who have already setup the action. However, provides the user with the option to use the new state if need be. So the default flow is Stale --> closed.
  • The Kubernetes issue lifecycle management follows the following flow:

Note: "This bot" refers to the triage-robot.

    This bot triages issues according to the following rules:
    - After 90d of inactivity, `lifecycle/stale` is applied
    - After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
    - After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed
    This bot triages PRs according to the following rules:
    - After 90d of inactivity, `lifecycle/stale` is applied
    - After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
    - After 30d of inactivity since `lifecycle/rotten` was applied, the PR is closed
  • The tests that has been added/updated to cover the new changes could be improved upon and suggestions are welcome.

Related issue:

Check list:

  • Mark if documentation changes are required.
  • Mark if tests were added or updated to cover the changes.

Add processRottenIssue
Add Options to support rotten issues
Update main.ts to process rotten related inputs
Update the Option enum to include rotten related variables
Update issue.ts to include function to get the rotten label
Add helper functions for rotten related options
@cooljeanius
Copy link

Description: This PR aims to add functionality that lets the user keep an issue in an intermediate state between stale and closed: rotten.

IMO the naming here is kind of counterintuitive; I'd expect stale to come first before rotten...

@mviswanathsai
Copy link
Author

Yes, it is stale -> rotten -> closed.

@cooljeanius
Copy link

Yes, it is stale -> rotten -> closed.

ah, got it, sorry, I just misunderstood at first... never mind...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants