Hello,

1. I have added probot to my account as indicated having:

   [ok tick] Read access to metadata and single file
   [ok tick] Read and write access to issues and pull requests
   

   And I'm an admin in an organization.

2. I have added the file .github/stale.yml to the organization I'm part of:

   https://github.com/python-mode/python-mode/tree/develop/.github

3. I have also waited for more than one hour for the bot to wake.

Still I have no results. Can you help me?

:)

I'm observing some double commenting over at atom/atom. Take a look at atom/atom#8267, atom/atom#8252 and atom/atom#8249

Is this an issue with stale bot, or something that is configured wrong by atom team?

https://sentry.io/probot/stale/issues/370700718/

: {"message":"Resource not accessible by integration","documentation_url":"https://developer.github.com/v3"}

This error is happening regularly for a few repositories that are unavailable due to a DMCA takedown.

The repository is still returned from GET /installation/repositories, which the days say "List repositories that are accessible to the authenticated installation", but all API requests against that repository return a 403 with "Resource not accessible by integration".

I think the fix for this should be to rescue these errors and just log them. There's not much else we can do if the repository is not accessible.

If I have a stale issue, then apply several new labels at once (here the security label is exempt, and the other two labels are not), I see multiple attempts to remove the label in the logs, and several of those attempts fail because the label has already been removed:

Not sure if this is particularly important since the outcome is as desired; just reporting for reference.

Here is one example were the comment was not made: rails/rails#26813 (comment)

Here is one example were the comment was made:
rails/rails#25774 (comment)

Maybe the app is hitting the rate limit?

If you use the GH integration, or even if you're running the bot yourself, it's a little difficult to tell if it's working or not. Documenting some of the default behavior and what to look for when troubleshooting as #35 suggests will certainly help, but it'd be great to get some feedback either when the bot starts up or the GH integration is configured/installed.

An idea to improve the on-boarding experience: auto-open an issue/PR somewhere that gives feedback that the integration was installed properly (whether through GH, or when you start the bot on your own hosted service installation).

One thing that I found useful for me was when I realized the bot uses the updated tag, I added that to the issue search bar to see what date made sense to set the initial daysUntilStale value to. Maybe this feature could use that value in the auto-open issue/PR comment to link to the issues (or prs) that would be set as stale when the bot starts running? That way people can see "oh, this is working, great!" and "Hrm...when I click this link, no issues are in that list." or whatever the case may be.

Something like:

Probot-stale has been configured for the <x> repo. 

<Something about whether or not a config file was found, and what probot-stale will do in either case.>

Within the next hour, probot-stale will comment on <y> issues and <z> PRs. You can see the list of issues [here](<link to repo's stale issues>) and the list of PRs [here](<link to repo's stale PRs>).

If you need to updated your config file based on the findings listed above, note that probot-stale will run as soon as changes to the `stale.yml` file are merged into the main repository branch.

I am not sure if this would be better to have the issue/PR auto-open on the repo with the config, or on some kind of "demo" repo. I don't know the code well enough or how integrations work, but either way I think it would be helpful for people to get started.

https://sentry.io/probot/stale/issues/371116657/

{
  "message":"Not Found",
  "documentation_url":"https://developer.github.com/v3/issues/#get-a-single-issue"
}

It's likely coming from

If that is the case, it's safe to catch this error and just ignore it.

Hey! It's great, but is a bit inconsistent to the other available bot apps. Most of them read config from .github/config.yml, but this reads from .github/stale.yml. Is this for reason or isn't updated?

It's not a big problem, but I like consistency and everything to be in one file.

During the recent update to atom/atom's stale configuration it seems that several issues were marked as stale without a corresponding comment from the bot alerting users that the issue might need attention, I only happened to notice this as I was looking through my issues for a specific comment.

An example issue where this happened is atom/atom#12020, with many more that can be found here.

After deploying throttling, this is no longer hitting abuse rate limits, but now it's hitting the normal API rate limits.

[error] { [Error: {"message":"API rate limit exceeded for installation:17424.","documentation_url":"https://developer.github.com/v3/#rate-limiting"}]

Currently the plugin runs a check against all repositories once/hour, which requires getting a list of all installations and all repositories and checking each repo for a config. An organization with a lot of repositories will quickly hit the rate limits.

Here are some ideas to make this more efficient and should avoid rate limit issues:

• on start, get all installations and repositories and set a random interval for checking each repository only if it has a .github/stale.yml
  • listen for a push event with a .github/stale.yml to enable the interval when a config is added
• Cache .config/stale.yml
• Increase interval from 1 hour

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.

https://sentry.io/probot/stale/issues/248660606/

Error: {"message":"Label does not exist","documentation_url":"https://developer.github.com/v3/issues/labels/#remove-a-label-from-an-issue"}

This has happened 74 times over the past couple weeks.

Here's my best guess as to what is causing it: a user is manually changing the labels, adding one label–such as pinned–and removing the stale label. This causes 2 webhooks to be fired. When the webhook for adding the other label is received, the payload shows that the issue still has the stale label on it and attempts to remove it.

Suggested resolution: Catch and ignore the 404 error when trying to remove the stale label.

"wontfix" does not accurately reflect the appropriate (candidate!) resolution for a stale issue, most of the time, and in fact can be very unfriendly when used incorrectly in such cases. Perhaps "waiting" or "on hold" would work better as default labels.

See here for an example of such a negative interaction that could have been avoided by better wording.

I wanted to try out probot-stale via GitHub integrations, so I set it up for this repository:

https://github.com/astrofrog/tmp-coverage

There is an issue that is over a year old so should be marked as stale, but this is not happening. I'm not familiar with how GitHub integrations work exactly, so how often does the bot run? Is there a way to run the bot manually to see a log that might show errors?

stale.markAndSweep never appears to be executed when we're performing a dry run. However, some methods invoked by stale.markAndSweep themselves perform logging during dry runs only. It's not clear to me that these statements will ever be reached. What am I missing?

@lee-dohm installed the stale plugin on @atom. I'll need to dig into why this triggered the abuse detection.

https://sentry.io/bkeepers/probot/issues/269777963/

Error: {"message":"You have triggered an abuse detection mechanism and have been temporarily blocked from content creation. Please retry your request again later.","documentation_url":"https://developer.github.com/v3#abuse-rate-limits"}

https://sentry.io/probot/stale/issues/250279765/

Error: {"message":"Bad credentials","documentation_url":"https://developer.github.com/v3"}

There's not a stack trace showing up for this error, so I'm not exactly sure what is causing it, but it's happened 680 times in the past few weeks.

My best guess is that the cached token is expiring seconds before the request is being made. While this should occur very rarely, the ttl for the cached token is exactly the same as the expiry on the token from GitHub, which is exactly the same as the interval for checking for stale issues: all are 60 minutes. So there could be some slight race condition where the token is still cached, but by the time the request gets to GitHub it has expired.

An easy way to test this would be to change the ttl on the cached token to 59 minutes.

From https://sentry.io/probot/stale/issues/427330638/

{
  "message": "Validation Failed",
  "errors": [{
    "message":"The year 1918 in \"1918-01-27T22:55:01\" is outside the accepted range 1970 to 2970.",
    "resource":"Search",
    "field":"q",
    "code":"invalid"
  }],
  "documentation_url":"https://developer.github.com/v3/search/"
}```

I started using Stale last Thursday and it hasn't commented on any of my old issues yet. I'm not quite sure why, but I suspect that it could be because of the label names I use for exemptLabels and staleLabel. Is it possible that the tool gets confused because my label names use square brackets?

I can't link to my repo as it is a private one, but here is my .github/stale.yml file.

# Stale https://probot.github.io/apps/stale/
# A way to keep our repo a bit cleaner by prompting for an update
# when an issue gets old, and closing that issue if it is not updated.
#
#
# Number of days of inactivity before an issue becomes stale
daysUntilStale: 60
# Number of days of inactivity before a stale issue is closed
daysUntilClose: 7
# Issues with these labels will never be considered stale
exemptLabels:
  - [Status] Maybe Later
  - Billing
# Label to use when marking an issue as stale
staleLabel: [Status] Stale
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment: >
  This issue has been marked as stale because it hasn't been updated in a while.
  It will be closed in a week.

  If you would like it to remain open, could you comment below
  and see what you can do to get things moving with that issue?
  Thanks! 🙇
# Comment to post when closing a stale issue. Set to `false` to disable
closeComment: true

What should I do then? I'll try to quote the values like so and see if it helps. If it does, maybe the docs should include an example like this?

Related: #62

I enabled stale on my repo today a few hours ago and not seeing any activity as yet. Wanted to make sure I had this enabled and setup correctly mostly.

pouchdb/pouchdb@c8bf3e4 is me merging the config, I enabled it quite a bit before that (#9 would be handy, I missed that)

Cheers

Hello and thanks for this awesome app

I wanted to report that Stale isn't working in any of my projects. There's Blueprint, for example, where there are a couple issues that are 3 days old but stale bot haesn't done anything to them.

Is there something wrong in the configuration stale.yml file?
Thanks in advance. 🙂

Hello

Firsrt of all, thanks for this awesome app

I wanted to ask you, if possible, to add a feature to create configs for a specific label.

For example, if I add the lable invalid to an issue/PR, I would like it to be marked as stale after 1 single day and get closed after 2 days. But for any other issue with any other label, I would like it to be marked as stale after 4 days and get closed after 7 days

I am not sure if this is already available but it would be awesome to have.

Thanks in advance :)

I'm not sure if this should be expected behavior or not, but if an issue is closed from inactivity, and then someone comments on it, the label gets removed.

I wonder if it shouldn't attempt to change labels if the issue is closed.

I would like to let issues sit for much longer than PRs before becoming stale.
I am able to keep on top of PRs so they are more active, but some issue sit around a long time before getting addressed.

Example of the bot applying and removing the "wontfix" label:
MinecraftForge/MinecraftForge#4673 (comment)

stale.yml config file:
https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/.github/stale.yml

I expect it to be using the "Stale" label, it has been until just recently.

https://sentry.io/probot/stale/issues/325727830/

{"message":"Resource not accessible by integration","documentation_url":"https://developer.github.com/v3"}

Happen quite a bit in the past several hours, I looked into the recent audit code and didn't immediately see anything that would've caused this.

cc/ @bkeepers

https://sentry.io/bkeepers/probot/issues/269778295/

Error: {"message":"Unable to create comment because issue is locked.","documentation_url":"https://help.github.com/articles/locking-conversations/"}

Error: {"message":"Unable to create comment because issue is locked.","documentation_url":"https://help.github.com/articles/locking-conversations/"}

cc @lee-dohm

In Rails we mark issues as stale after 90 days and we want to close them if there is no response after one week.

For what I could get in the code seems that the sweep time is equal to the double of the number of days configured to mark as stale, since marking as stale changes the updated_at attribute and now that issue will only be found by the getIssues() function after the updated_at is greater than 90 days.

Should we have different schedules for mark and sweep phases?

It would be good to be explicit about what constitutes activity. For example, does adding a label constitute activity? Or changing a milestone? In my case I would like to be able to configure this to say that I specifically want activity to be linked either to a pushed commit or a comment, but ignore changes in labels, milestones and other such events. Is there a way this could be done?

👋 Wanted to memorialize a conversation that @gr2m @bkeepers @JasonEtco and I had with @keithamus at GitHub Universe this past week. Keith brought up a really valid point about first time contributors and the way a bot closing out their issue might affect future contributions to open source. Everyone mentioned above, please feel free to edit my explanation as you see fit.

Apologies for my paraphrasing: There are two types of issues that end up getting closed. There are issues where the submitter has done their best to reproduce and for one reason or another the issue doesn't get attention. The type is when the submitter is not responding or might not be following instructions. This type makes perfect sense for stale. It will close out issues that don't meet the bar for human interaction.

However, the first type of issues where the submitter has done everything in their power to help describe the issue, there might be an opportunity to change the tone or interaction so that we could help empower new comers rather than have them get shut out by a bot.

Examples

I tried to pull up a few issues to try and describe these different circumstances.

Here is a situation where a person opened an issue without filling out the proper documentation: atom/atom#15889 This is a perfect candidate for stale or another bot to reply as rsese did in this instance.

Here is a situation when the original opener of the issue styurin got an answer from a member of the project and never replied. In this case it seems that it's reasonable to close the issue b/c the original submitter never followed up: atom/atom#12964

Here is a situation when the user took time to report an issue and someone added a label but there was no further interaction. I would imagine the issue got fixed at some point b/c the original submitter, misaghshakeri, never replied. atom/atom#12548 However, I wonder if some sort of interaction or nuance could help provide context.

Possible Solutions

We could use the first-timer property returned from the GraphQL endpoint to change the behavior of the app.

We could build a heuristic for how new a person is to GitHub to provide a nuanced response to stale.

We could be more opinionated/prescriptive on how we ask users to write their stale comment text.

In short, I think stale is awesome. It's adoption and resulting data gives us a really cool opportunity to re-asses its interactions and further investigate the tone, context, and persona of stale that will best serve the needs of first time contributors up through maintainers.

This plugin doesn't check if the config.staleLabel already exists on a repo, it just starts adding it to issues. It appears there is a race condition on GitHub where it will create duplicate labels if there are multiple issues being updated at the same time.

Sorry @electron team 😢

cc @zeke @groundwater @kevinsawicki

Over at https://github.com/campus-experts/training, we're looking to use stale to handle neglected issues and PR's, however we would really like to put different durations across different labels.

Example use case

We have one training module which takes a long time to work through. It's quite typical that a user submits a first draft and we then review it. Once it's reviewed it can sometimes take a while for a user to push their changes as they often take a while to complete, we're talking on a scale of 2-3 weeks. However other modules can be much quicker and fixes can often be carried out in a matter of minutes and we want the expected turn around to be much quicker.

It would be fantastic if we could enter an array of labels with some override values, falling back to the top level stale settings. IE:

label x - is stale after 1 day and closed after 1 more
label y - is stale after 14 days and closed after 3 more days

It'd be great to have the ability to run this bot only against certain labels – to whitelist labels, rather than blacklist all labels but those few we want.

@bkeepers It appears that the stale bot isn't working. GitHub's APP server and API status says it is all good, but when I click the link listed at the top of the repo, I get a 404 Error:

https://github.com/apps/probot-stale

Based on my settings in my stale config file, there are about 4 days of issues that should have been marked as stale, but have not received the stale label or a bot comment. There are also issues open that were marked as stale 11 days ago, but have not been closed or updated in any way (we're using the default setting of 7 for the daysUntilClose option).

It would be nice to be able to configure whether probot closes only pull requests, or also issues. For our project issues should be able to stay open forever, and we would only want this to apply to pull requests. If this is already possible, can the README be updated to show how?

https://sentry.io/probot/stale/issues/307099740/ is an error caused by an installation that has an array value for staleLabel, which is not expected. In this case, passing that parameter on to the GitHub API doesn't cause any harm, but there could be other instances where it does.

We should do an audit of all config values to ensure they're properly checked before being used in an API request.

Error: {"message":"Invalid request.\n\nFor 'properties/name', [\"wontfix\", \"duplicate\", \"invalid\"] is not a string.","documentation_url":"https://developer.github.com/v3/issues/labels/#create-a-label"}

At https://github.com/sequelize/sequelize we have a lot of long standing issues that are indeed valid feature requests and have a lot of valuable discussion on it. But almost all features come from contributions, as most features are complex and we maintainers don't have time to implement it if we don't need it.
But the majority of issues are support issues that are missing info or questions.
I would like to start by automatically closing stale issues that have the "needs more info" label instead of closing all issues except specific labels.

these can often linger in repos

After configuring the probot-stale integration, I learned several things that weren't documented very well, or were difficult to find. Documentation should be added to the README to help people troubleshoot:

• The stale probot runs every hour.
• When it runs each hour, the time it starts is randomly determined.
• "stale" issues doesn't mean just when a user comments on an issue. It can also mean when a milestone is applied. It has to do with the updated search item.
• When the bot is first started (or the integration is installed, depending on your setup method), and the config file is already in place, the bot will not comment on things right away. However, if the config file is pushed up after the bot starts, it will start searching for issues immediately. This is true for configuration file changes as well.

This issue is similar to the request/discussion in #34, but includes a couple of other things I found helpful once I understood how everything worked. This is also related to the questions posed in #33.

Debugging the search that is being made I saw that a search for open PRs that are not updates in the last three months return an empty result even that the repository have a lot of stale PR as it is the case of activeresource.

https://github.com/rails/activeresource/search?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+updated%3A%3C2017-02-04T22%3A51%3A53&type=Issues

https://github.com/rails/activeresource/pulls

Maybe the GitHub search can't be used for that?

In our project we would like to leave stale PRs open even if they do not receive any activity. As there is no documentation regarding how to achieve this, we naively tried to comment out

# daysUntilClose: 7

Apparently, this does not help as the default value of 7 is picked up.

Would be helpful if it was possible to write something like daysUntilClose: false or perhaps a separate option closeStale: false.

This issue happens infrequently, but often enough that it seems like there is something consistently causing it.

There's not a lot of info in the error log:

{"message":"Bad credentials","documentation_url":"https://developer.github.com/v3"}

https://sentry.io/probot/stale/issues/372586507/

We're currently using probot/stale at Moya and the bot is marking issues as stale but not returning to close them after the specified daysUntilClose setting.

Can anyone help troubleshoot this issue? You can find the stale.yml file here

I'm aware that probot uses the updated search qualifier to find stale issues and pull requests, but none of the issues that were marked stale have been modified since.

Any help would be greatly appreciated 😅

I'm trying to use probot-stale as a plugin to a large bespoke bot but I just realised that the version on npm is 5 months old and using "probot-visitor" which is causing a bunch of errors. I'm assuming this is because that module has been renamed to "probot-scheduler" quite a while ago and had numerous updates to it.

Would it be possible to bump the package version of this module and publish it to npm again? That would make this usable as a plugin again.

From the README:

Heads Up! This integration will run as soon as you install it on your repository. If you want to change any of the settings, do it before installing.

Right now, when this integration is installed, it will immediately run on all repositories that it has access to using the default configuration, which means every issue older than 60 days gets commented on and labeled.

This can be a little jarring, so I'm wondering if it should require .github/stale.yml to at least be present to run.

Thoughts?

@zeke @lee-dohm @parkr

I noticed at licensee/licensee#222 (comment) an issue closed by stalebot although it had been cross-referenced by a pull request in the same repo 3 days before. This feels like a false positive to me: the issue isn't stale if it is being worked on in a PR.

The result seems suboptimal for someone interested in and subscribing to an issue: they get a disappointing closed-by-stalebot notification, and never get (when it happens) a satisfying closed-because-fixed-by-PR-merged notification (I could be wrong about this, based on my vague memory).

I guess that weeding out by virtue of being referenced from a commit or PR would require another step after searching based on update time, presumably with https://developer.github.com/v3/issues/timeline/

Just an idea! 😄

First off, thank you for this great service. I'm testing this out on one of the repositories that I help maintain and it has already been really useful.

Secondly, it would be great if there were an option for the bot to comment on an issue when the stale label is removed due to the issue being updated. Just something like "Thanks for commenting. This issue is no longer marked as stale."

Having an option to lock issues that have been closed for x number of days would be a nice enhancement. Thinking of;

1. Warn

After x days of inactivity, leave a "comment" ("this issue / PR looks to be inactive, please close the issue if this issue is resolved, or leave a comment if this is still an issue. This issue will be automatically closed after x days")

2. Close

After x + y days of inactivity; leave a "comment" and close the issue

3. Lock

After x + z days, leave a "comment" and lock the conversation

All steps should be optional (i.e., some repositories may not want to leave a warning first; some may not want automatic closing, and some may not want automatic locking)