As raised in uber/baseweb#1892, it seems like new comments do not remove the Stale label. Do we miss anything in our configuration?

name: 'Close stale issues'
on:
  schedule:
    - cron: '0 0 * * *'

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v1
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          stale-issue-message: "This issue is stale because it has been open 30 days with no activity. If it's still valid, please remove the stale label or comment on the issue, otherwise this ticket will be closed in 5 days"
          days-before-stale: 30
          days-before-close: 5

I have tried everything and still can't get my stale action to work?

Stale Workflow

I have the following issue. It was marked as stale 8 days ago. But the stale bot never closed the issue.

dynamoose/dynamoose#909

GitHub Action logs (https://github.com/dynamoose/dynamoose/runs/744186714?check_suite_focus=true):

Found issue: issue #909 - [BUG] can't define a schema which includes a list of objects in typescript last updated 2020-05-30T00:26:15Z (is pr? false)
59
Found a stale issue
60
Checking for label status:stale on issue #909
61
Issue #909 marked stale on: 2020-05-30T00:26:15Z
62
Checking for comments on issue #909 since 2020-05-30T00:26:15Z
63
Comments not made by fishcharlie or another bot: 0
64
Issue #909 has been commented on: false
65
Issue #909 has been updated: true
66

Any reason why this would be occurring?

I want every pr/issue that is defined in a milestone and exempt-from-milestones is true, that this pr/issue will not get staled/closed, because if a pr/issue is already defined in a milestone it is already recognized by the team and was planned. So there is no need to close/stale it.

name: "Close stale issues"
on:
  schedule:
  - cron: "0 0 * * *"

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/stale@v1
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        exempt-from-milestones: true

Great project :-)!

Having a bot close issues is considered to be very rude under some circumstances so it would be great to be able to decide if this action does not close issues at all.

Something like days-before-close: -1 should serve as a flag for this and let the project maintainers/authors do any actual closing.

A workaround could be to add a very very long time to days before closing, but that does not seem like the cleanest solution.

Hi there,

I have a comment related the issue #28.

🙏 for having implemented this a few days ago, but I am looking for the old behavior 😅

We are introducing this action on many repos that have stale issues for a very long time.
So I was expecting the behavior as it is sated in the configuration :

days-before-close:
    description: 'The number of days to wait to close an issue or pull request after it being marked stale. Set to -1 to never close stale issues.'
    default: 7

1. Mark the issue as stale and post a comment, which notifies the author.
2. Then, after days-before-close close the PR that has been marked stale,

Would there be a way to get both behavior ?
May as @NBprojekt suggested with a value of 0 ?

Thanks again for your work 😄

It would be nice to exempt Force-Pushed updates on an issue from counting as the last updated event.

Here is an example from one repo where the last "direct" update was on Aug 11, 2017, but a series of force-pushes to the branch causes the update to be May 5, 2020 (google/flatbuffers#2789). This causes this stale action to not properly tag it.

I upgraded to 3.0.1 yesterday, but it seems the run from this morning removed the label from some tickets:

3liz/lizmap-web-client#727

Is-it because the bot didn't recognized it was a custom GitHub token in the action?
Related to #21 ?

I am proposing to the Apache Spark community that we use this Action to manage the number of open PRs we have.

Enabling this Action on a large repo with so many contributors is not a single-step task. Project committers will want to see how the Action works and iterate several times on the wording of things and, more importantly, on the filter that selects which PRs to close or not.

My desired workflow is to submit a PR to the Spark repo adding this Action in. From the PR, I want to be able to iterate on the filter criteria and see what PRs would be impacted, without actually impacting anything.

Is there way to do a dry run of this Action, where we can see the list of PRs that would be impacted, along with the details of how each one would be impacted, without actually touching any PRs?

It would be great if this workflow would add a label, for example "wontfix" (i.e. user defined), to issues that where closed due to being stale.
If this is currently possible, please then change the title of this issue to something like: "add close label to documentation".

It is neither marking as stale or closing the PRs. The github log is:

Hi.

I would love to use this action for my case, but that will require a small tweak. Specifically, I need to run the stale logic over all the issues in a specific milestone. It would be great to be able to specify milestone only for which the issues will be configured.

A more universal option would be to have a filter option (a github issue query text), which the user will specify in a workflow .yaml file, and that will flow directly into here: https://github.com/actions/stale/blob/master/src/main.ts#L33

I got this message:

  Set up job3s
  LTS
Current runner version: '2.263.0'
Operating System
  Ubuntu
  18.04.4
  LTS
Virtual Environment
  Environment: ubuntu-18.04
  Version: 20200518.1
  Included Software: https://github.com/actions/virtual-environments/blob/ubuntu18/20200518.1/images/linux/Ubuntu1804-README.md
Prepare workflow directory
Prepare all required actions
Download action repository 'actions/stale@v3'
  Run actions/stale@v33s
    debug-only: false
Run actions/stale@v3
  with:
    repo-token: ***
    days-before-stale: 60
    days-before-close: 7
    stale-issue-message: This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
  
    stale-pr-message: This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
  
    stale-issue-label: stale
    stale-pr-label: stale
    operations-per-run: 30
    remove-stale-when-updated: true
    debug-only: false
(node:2791) UnhandledPromiseRejectionWarning: TypeError: (s || "").replace is not a function
    at escapeData (/home/runner/work/_actions/actions/stale/v3/dist/index.js:5050:10)
    at Command.toString (/home/runner/work/_actions/actions/stale/v3/dist/index.js:5044:35)
    at issueCommand (/home/runner/work/_actions/actions/stale/v3/dist/index.js:5007:30)
    at Object.issue (/home/runner/work/_actions/actions/stale/v3/dist/index.js:5011:5)
    at Object.error (/home/runner/work/_actions/actions/stale/v3/dist/index.js:7217:15)
    at /home/runner/work/_actions/actions/stale/v3/dist/index.js:3741:18
    at Generator.throw (<anonymous>)
    at rejected (/home/runner/work/_actions/actions/stale/v3/dist/index.js:3718:65)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:2791) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:2791) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
  Complete job

Is this an error?

Hi,

I'm trying to use this github action to auto-close issues for a specific label that have had no activity in the last N days.

Here's how my configuration looks like

name: "Close stale issues"
on:
  schedule:
  - cron: "0 0 * * *"

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/[email protected]
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        only-labels: 'waiting-for-response'
        stale-issue-message: 'This issue is stale because it has been open 14 days with no activity. Remove label or comment or this will be closed in 2 days'
        days-before-stale: 14
        days-before-close: 2

However, it generates a warning:

Unexpected input 'only-labels', valid inputs are ['repo-token', 'stale-issue-message', 'stale-pr-message', 'days-before-stale', 'days-before-close', 'stale-issue-label', 'exempt-issue-label', 'stale-pr-label', 'exempt-pr-label', 'operations-per-run']

As per the code it seems only-labels is a valid option. What am I missing?

Rather than having the action close stale pull requests, it would be useful if the action could re-notify any requested reviewers that they have not given their review yet - ignoring any reviewer who has submitted a review or comment.

What exactly is the operations-per-run parameter? I tried running this action in my repo in debug mode and got a warning "Reached max number of operations to process. Exiting." without any other output.

Hi, we've just started using this action on one of our repos and I noticed that it's reporting a "check" against our commits for everything that's in an open PR. This is resulting in some PR commits as having many such "checks" against them, is there a way to avoid this?

Here's a recent example of a PR that was open over night having ~18 "checks" against it for the stale action workflow:

I'm concerned that this will drown out the otherwise useful checks that we're using for CI reporting on our PRs.

This may relate to #13

In our PRs under the scenarios -

on:
  pull_request:
    types: [labeled, unlabeled, opened, edited, reopened, synchronize]

The checks are showing up multiple times and preventing a green due to past failed checks.

e.g. if a "stale" label already exists in the repo and stale is configured to use "Stale", the item will keep getting tagged instead of closed.

Locked issues/PRs cannot be commented upon without elevated user permissions. In the "Stale" Probot App, we saw that not excluding locked issues/PRs from the issues being processed led to API failure responses due to comment creation being blocked for the bot.

Easy workaround: ignore locked issues/PRs. This may not be ideal but it avoids failures and would also provide more consistent behavior with the "Stale" Probot app.

Out of curiosity, what are the pros and cons of this vs. the stale bot

Is it a more recent rewrite using GitHub Actions?

Are there any difference in use cases that they respectively unlock?

It would be nice to have the option to ignore draft PRs as they are implied to be not ready and can be filtered out.

We have the action with this configuration:

    steps:
      - uses: actions/stale@v1
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          days-before-stale: 13
          days-before-close: 1
          stale-pr-label: Stale
          stale-pr-message: "Pull request hasn't had any activity recently. Will be closed tomorrow if it remains like this."

The action has been running for a couple days, and yet none of the PRs marked as stale on the first day were closed on the second day:

Maybe I didn't understand how days-before-close is supposed to work, but isn't it supposed to close things 1 day after the Stale label was added?

(Just to note, there hasn't been any activity on those PRs since the action run)

Sometimes it’s annoying when stable bot repeatedly nag users. For example:

travis-ci/travis-ci#9430 (comment)

I think it would be helpful if users can specify exponential backoff. For example, first mark as stale in 2 months, then 4 months, then 8 months, then 16 months, then give up (or add a “long-running issue” label).

This is with the latest v3 tag using commit (b6f9559) which is the latest as of today. This is the log output from the run:

https://github.com/eclipse/omr/runs/709719104?check_suite_focus=true

There is a problem towards the end in eclipse/omr#3847:

Found issue: issue #3847 - Just-In-Time code patching framework used in CS read barrier  last updated 2019-09-13T12:54:23Z (is pr? false)
Marking issue stale because it was last updated on 2019-09-13T12:54:23Z and it does not have a stale label
Marking issue #3847 - Just-In-Time code patching framework used in CS read barrier  as stale
Found a stale issue
Checking for label stale on issue #3847
Issue #3847 marked stale on: 2020-05-26T14:44:21Z
Checking for comments on issue #3847 since 2020-05-26T14:44:21Z
Comments not made by fjeremic or another bot: 0
Issue #3847 has been commented on: false
Issue #3847 has been updated: false
Closing issue because it was last updated on 2019-09-13T12:54:23Z
Closing issue #3847 - Just-In-Time code patching framework used in CS read barrier  for being stale

The configuration on our repository can be found here:
https://github.com/eclipse/omr/blob/6367999e3f811c226a48cfa03df267ef3e561d29/.github/workflows/stale.yml

        days-before-stale: 180
        days-before-close: 60
        exempt-issue-labels: 'backlog'
        stale-issue-label: 'stale'
        stale-pr-label: 'stale'

The problem seems to be because eclipse/omr#3847 is older than 180 days, the action correctly marks it as stale on the following line:

however it sets the isStale variable to true which then forces the logic on line 173 to run:

Within this function we use issue.updated_at to determine whether the now stale issue should be closed:

However this is NOT correct since the logic on line 166 has just marked the issue as stale, and the issue.updated_at was not changed accordingly, so we proceed to close the issue without waiting for days-before-close days to pass. This is a bug in my opinion, and to fix it we should be updating the issue.updated_at if we have just marked the issue with the stale label.

For instance, we'd like to exclude issues labeled help wanted from the auto-closer, because we'd like contributors to pick these up down the line.

I'm testing out 3.0.4 and it looks like putting in a comment or mentioning an issue that is marked STALE does not remove the flag.

I'm using a stale.yaml file that looks like this:

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/[email protected]
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        days-before-stale: 1
        days-before-close: 1
        stale-issue-message: >
          Stale message goes here.
        operations-per-run: 25
        stale-pr-message: >
          Stale message goes here.
        stale-issue-label: 'STALE'
        stale-pr-label: 'STALE'
        exempt-issue-labels: 'WIP'
        exempt-pr-labels: 'WIP'
        remove-stale-when-updated: true

I created an issue that got marked stale this morning and I added a comment. Then re-ran the workflow and I see this in the output:

Found issue: issue #1 - Test Issue 1 last updated 2020-05-27T16:21:57Z (is pr? false)
Found a stale issue
Checking for label Stale on issue #1
Issue #1 marked stale on: 2020-05-27T16:21:57Z
Checking for comments on issue #1 since 2020-05-27T16:21:57Z
Comments not made by william76 or another bot: 0
Issue #1 has been commented on: false
Issue #1 has been updated: true
Stale issue is not old enough to close yet (hasComments? false, hasUpdate? true

It sees that the issue was updated, but it's not clearing the stale label. In the output I don't think the workflow is seeing the comment that I added after the issue was marked stale.

Adding a mention to a STALE issue from a PR or other issue also appears to not reset the flag.

The repository where I'm testing this is at https://github.com/william76/workflowTest/issues

Does this action work for PRs from forked repos?

From the options available, I don't know how to configure the action to not close stale issues/PRs. I just want the action to mark them as Stale but nothing more.

I guess I can set days-before-close: 999999, but is there a better way?

The behavior I'm looking for is that a issues / PRs gets immediately closed after the 'stale' label was added.

I thought this would do the thing but it did not close the issue after adding the label, the issue got closed 1 day after the label was added.

days-before-stale: 2
days-before-close: 0

Also is there a posibility to locked the issue after it was closed?

Inspired by Ionictron, intended behavior

I have yesterday added this action to my project.
The flow ran tonight and closed half of my issues.
They were stale, but instead of only marking as stale and wait a week it closed it immediately.
This seems like a critical bug to me.
See here:
https://github.com/IsraelHikingMap/Site/blob/master/.github/workflows/stale.yml
https://github.com/IsraelHikingMap/Site/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

On the stale bot, we were able to ignore a list of labels from the runs

# Only if issues that are not triaged
exemptLabels:
  - "1. to develop"
  - "2. developing"
  - "3. to review"
  - "4. to release"
  - security

Could be nice if we could as well :)

On another note, the description for the exempt-issue-label config is not really appropriate I'd say: The label to apply when an issue is exempt from being marked stale. I would go for something like The label to ignore. Any issues with that label will not be processed.

Hi,

Is it possible to customize the bot's name and avatar?
Sorry if this question doesn't belong here, I've searched all around and couldn't find an answer.

Hi all! I'm trying to make use of the latest version of the action, which according to the Marketplace, is v2.0.0. However, the docs in this repo show actions/[email protected] or actions/stale@v1. Should I be using actions/stale@v2? I'd appreciate any clarification on this, thanks!

Hi there,

good job on this action. We are using it in some of our projects and it works great.

I thought I cross-post here nevertheless as it might be from interest for you even though I don't think it is an issue with your code:

https://github.community/t5/GitHub-Actions/Action-not-run-and-no-logs-available-action-stale/m-p/42795#M5120

Summary: the action/stale is never run and no logs are available for our repository in https://github.com/comit-network/comit-rs.

source code: https://github.com/comit-network/comit-rs/blob/master/.github/workflows/stale.yml

Cheers,
Philipp

Hi --

I wanted a slightly more complex workflow with the stale action that I thought would work, but doesn't appear to be. I may have misconfigured it, but it's not clear to me how; I'm hoping someone can point me in the right direction.

My desired activity is:

1. Mark a PR stale after five days
2. Twenty-five days after that, mark it with another label, more threatening :)
3. Five days after that, close it.

To achieve this, I actually configured two versions of the action on the repository as follows:

.github/workflows/stale.yml:

name: Mark stale issues and pull requests
...
    - uses: actions/stale@v3
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-pr-message: "This issue has been automatically marked as stale because it has not had recent activity."
        stale-pr-label: "stale :bread:"
        days-before-stale: 3
        days-before-close: 999
        exempt-pr-labels: "On Hold :stop_sign:"

.github/workflows/closer.yml:

name: Close stale issues and pull requests
...
    - uses: actions/stale@v3
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-pr-message: "This issue will be closed soon. Please mark it 'On Hold :stop_sign:' to skip."
        stale-pr-label: "WILL BE CLOSED :skull_and_crossbones:"
        days-before-stale: 25
        days-before-close: 5
        exempt-pr-labels: "On Hold :stop_sign:"

My expectation is that a stale PR would be marked stale on day five so its updated_at would bump up, 25 days later the other action would pick it up and mark it with the new label (so its updated_at would again bump up), and then five days later it would be closed.

The first action goes as expected, and the marking of the second goes as expected -- but the closing event does not happen as expected. Here's an example log:

Found a stale pr
Checking for label WILL BE CLOSED :skull_and_crossbones: on issue #2318
Issue #2318 marked stale on: 2020-05-23T03:04:26Z
Checking for comments on issue #2318 since 2020-05-23T03:04:26Z
Comments not made by jwilner or another bot: 0
Issue #2318 has been commented on: false
Issue #2318 has been updated: true
Stale pr is not old enough to close yet (hasComments? false, hasUpdate? true

The PR was marked with WILL BE CLOSED ☠️ on 2020-05-23T03:04:26Z. Yet it's far more than five days since then and the PR has not been closed.

When I check the code here, the updatedSince logic instead seems to be waiting 30 days after the last update: https://github.com/actions/stale/blob/master/src/IssueProcessor.ts#L204-L207. I would expect this check to only be passing daysBeforeClose, not daysBeforeClose + daysBeforeStale, since adding the stale label updates the updatedAt.

Clearly though this must be working for other people, so I assume I've misconfigured something.

Any help would be greatly appreciated.

Like the old stale bot, we had onlyLabels to force every issue/ to have all of the provided labels before being processed.

# Only issues or pull requests with all of these labels are check if stale. Defaults to `[]` (disabled)
onlyLabels:
- "needs info"
- "0. needs triage"

For the "Stale" Probot App, we have received a fair number of reports ([1], [2], [2]) that the app was unexpected operating on issues and PRs that had already been closed. Given that our query to the Issue Search API explicitly included the is:open condition, we determined that this appears to be a more recently introduced bug or shortcoming of the Issue Search API itself -- likely due to outdated indexing.

Luckily, since we are already retrieving the list of issues to be operated on, it was easy enough to add the simple and inexpensive workaround of just checking each issue's state value to verify it was still "open" before processing it.

The same type of workaround should be included in the Stale action as well.

Please add exempt-milestone and exempt-project to ignore Issues and Pull Requests placed in some milestone and project respectively.

I tried running the code below on a test repository. The issues get tagged appropriately but then they get closed despite using the days-before-close: -1 flag.

Steps to reproduce:

1. Create new repository
2. Add script below to .github/workflows
3. Open a couple of test issues
4. Wait for workflow to run

name: Mark stale issues and pull requests

on:
  schedule:
  - cron: "10 * * * *"

jobs:
  stale:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/stale@v1
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-issue-message: 'This issue has not been updated in the last TBD days'
        stale-pr-message: 'This PR has not been updated in the last TBD days'
        stale-issue-label: 'stale'
        stale-pr-label: 'stale'
        days-before-stale: 0
        days-before-close: -1

It'd be nice to have an option to only run on a certain label (the opposite of exempt-issue-label), for example to only process issues labelled as question. Of course this should be implemented for PRs as well.

So since discussions isn't enabled yet for this repo, I shall ask my question here... Is there a way to have this action just mark something a stale but not close the PR or issue? Often times people open an issue and there is no follow up, but we also don't want to close the issue because they haven't gotten back to following up in a certain amount of time. It looks like the closing is required

daysBeforeClose: parseInt(
    core.getInput('days-before-close', {required: true})
),

Would there be any opposition to not making this required? Furthermore, would there be any opposition to making the marking of stale and closing different between issues and PRs? For example, maybe someone wants to close a PR immediately after being marked as stale but might want to close an issue 2 days after.

Does a mention from another issue or pull request count as activity on an issue and reset the inactivity counter?

For example:

• Workflow marks issues as inactive after 5 days
• Issue A is filed on Jan 1
• Issue B is filed on Jan 4 and mentions issue A in it.

If Issue A is otherwise not touched, would it get flagged as stale on Jan 5th or 9th?

If the answer is Jan 5th... it would be useful to have an option in the yaml, say include-mentions-as-activity or something like that so that if an issue is mentioned in a PR or another issue the stale timer would get reset for that issue.

This issue got marked incorrectly as Stale: dynamoose/dynamoose#543

As you can see that issue has the status:todo label on it. But in my workflow, you can see that exempt-issue-labels includes status:todo label as one of the exempt labels.

https://github.com/dynamoose/dynamoose/blob/ff49d9727a0d9b9b7d883c3dec76ad3734b1f05a/.github/workflows/cron.yml#L16

Why did this issue get marked as stale?

Description

Currently there's no option for not adding a comment while marking an issue or a pull request as stale. As a real life example use case, a bot on fastlane repository only adds a label status: needs-attention to the pull requests that have been hanging without any action for a while. It's a handy way to express the need for an action to be taken without an explicitly pinging a given person.

Proposal

I'd like to propose adding two parameters to the action's inteface:

skip-stale-pr-message:
  description: 'Skip adding stale message when marking a pull request as stale.'
  default: false

skip-stale-issue-message:
  description: 'Skip adding stale message when marking an issue as stale.'
  default: false

No breaking changes, only opt-in.

Empty stale-pr-message / stale-issue-message will always take a precedence over skip-stale-pr-message / skip-stale-issue-message.

Workaround

Create a custom GitHub Action based on an official stale action implementation.

I'll gladly implement this feature if a proposal is accepted 😊

It would be a useful feature to be able to only mark issues as stale once another user has added at least one comment in response, for example where issues are used to ask questions about a repository.

We really need units (so far have just been using integration tests)

As you can see in the following event, the github-actions but added the stale label, then removed it right away. Why is this?

dynamoose/dynamoose#893 (comment)

You can also see my workflow file here:

https://github.com/dynamoose/dynamoose/blob/master/.github/workflows/cron.yml