probot / stale Goto Github PK
View Code? Open in Web Editor NEWA GitHub App built with Probot that closes abandoned Issues and Pull Requests after a period of inactivity.
Home Page: https://probot.github.io/apps/stale/
License: ISC License
A GitHub App built with Probot that closes abandoned Issues and Pull Requests after a period of inactivity.
Home Page: https://probot.github.io/apps/stale/
License: ISC License
Hello,
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.
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
I have also waited for more than one hour for the bot to wake.
Still I have no results. Can you help me?
:)
"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.
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.
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.
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.
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
Line 28 in 44c7a9c
If that is the case, it's safe to catch this error and just ignore it.
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?
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.
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
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:
.github/stale.yml
push
event with a .github/stale.yml
to enable the interval when a config is added.config/stale.yml
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.
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
these can often linger in repos
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?
👋 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.
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.
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.
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.
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?
🚨 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.
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/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.
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)
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.
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
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 😅
🚨 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.
@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"}
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 😢
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
.
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.
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! 😄
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:
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.
@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).
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
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?
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 :)
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.
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?
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?
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. 🙂
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."
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"}
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/pulls
Maybe the GitHub search can't be used for that?
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"}
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
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.
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'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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.