Skip to content
This repository has been archived by the owner on May 20, 2023. It is now read-only.

Does not unmark when activity on PR when using keywords pulls: and issues: #134

Closed
johlju opened this issue Jun 19, 2018 · 15 comments
Closed

Comments

@johlju
Copy link
Contributor

johlju commented Jun 19, 2018

In this PR dsccommunity/xSmbShare#20 (comment) it did not remove the stale label 'abandoned' when there was activity on the PR (see style.yml). Looking at the code it seems is not using the `this.getConfigValue(type, 'staleLabel')' or similar to get the correct value.

stale/index.js

Lines 36 to 37 in 628cbc9

const staleLabelAdded = context.payload.action === 'labeled' &&
context.payload.label.name === stale.config.staleLabel

@bkeepers Can I get your input on this one? Could this be the problem?

@hiimbex
Copy link
Contributor

hiimbex commented Jul 3, 2018

The line you linked to is checking to make sure the event wasn't stale bot adding a label that would otherwise count as activity. So in your case this context.payload.action === 'labeled' would be false since the actions would have been issue_comment.created.

The code that actually does the unmarking is here, but after looking through this for a bit, I don't immediately see the issue. Let me know if you can reproduce this anywhere.

@johlju
Copy link
Contributor Author

johlju commented Jul 3, 2018

@hiimbex Thanks for looking at this - example of it not being removed can be seen here johlju/DebugApps#16. Just commented on the PR but the label is not getting removed. Feel free to test/debug anyway you want in this repo, it is just a "lab" for testing/verifying Apps.

@hiimbex
Copy link
Contributor

hiimbex commented Jul 10, 2018

Hmmm just guessing, but looking at your stale.yml I see https://github.com/PowerShell/xSmbShare/blob/dev/.github/stale.yml#L7 in which you never plan to close the PR, so maybe that's causing this unmark run never to happen?

I'll try to look into this more shortly.

GitHub
Contribute to xSmbShare development by creating an account on GitHub.

@johlju
Copy link
Contributor Author

johlju commented Jul 11, 2018

It could be, because it unmarks for issues, which is configured to be closed.

@johlju
Copy link
Contributor Author

johlju commented Jul 11, 2018

@hiimbex It looks like it actually works for pushes, but not other activity (what I have seen yet)? 🤔

I saw these below, where Stale actually correctly removed the abandoned label (both when user pushed).
dsccommunity/FailoverClusterDsc#177 (comment)
dsccommunity/SqlServerDsc#1052 (comment)

So isn't seeing the correct (all) events for example when commenting? 🤔

@johlju
Copy link
Contributor Author

johlju commented Aug 2, 2018

@hiimbex After seeing this issue a few times more, it seems Stale removes the "stale" label ('abanonded' in my case) when there is a push to a PR, but it seems it does not remove the "stale" label when there is a "pull request comment" event.

A comment was made here, but Stale did not remove the label.
dsccommunity/CertificateDsc#134 (comment)

@stale
Copy link

stale bot commented Oct 31, 2018

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Oct 31, 2018
@johlju
Copy link
Contributor Author

johlju commented Oct 31, 2018

This is still an issue since the abandoned label is not removed when commenting on a pull request (as per my previous comment).

Updating so this issue is active.

@stale stale bot removed the wontfix label Oct 31, 2018
@hiimbex
Copy link
Contributor

hiimbex commented Nov 1, 2018

Sorry I haven't had time to look into this further. If you'd like to investigate and open a PR, I'd be happy to review it, otherwise I don't think it's likely this will be prioritized in the near future.

@infotexture
Copy link

@hiimbex wrote:

Let me know if you can reproduce this anywhere.

I've seen similar behavior on issues in the DITA Open Toolkit repository where the Stale bot is enabled, but does not reliably remove labels on activity, so the problem is apparently not limited to PRs.

In dita-ot/dita-ot#2286 (comment), the Stale bot added a comment and label to an old issue as expected, but failed to remove the stale label a few days later when the original poster added a comment dita-ot/dita-ot#2286 (comment), which should have removed the label according to the Probot description:

If the Issue or Pull Request is updated, or anyone comments, then the stale label is removed and nothing further is done until it becomes stale again.

Since the label was not removed, the issue was later closed although it shouldn't have been.

One of the project maintainers subsequently re-opened the issue, which the Stale bot noticed and removed the stale label.

I double-checked the configuration, but don't see anything that would seem to prevent Probot from removing the the stale label when comments are posted.

— Any ideas?

@max-sixty
Copy link

We're seeing the same bug here: pydata/xarray#2797. It's happened on multiple issues.

I'm looking at the configurations between xarray and @infotexture to see if there's some similarity. We both use the stale label, which is not default. Could that be a cause?

Thanks for the awesome tool

@stale
Copy link

stale bot commented Jun 1, 2019

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Jun 1, 2019
@johlju
Copy link
Contributor Author

johlju commented Jun 2, 2019

Still relevant. Someone in the community just need to help resolve this. 😊

@stale stale bot removed the wontfix label Jun 2, 2019
@max-sixty
Copy link

We haven't seen this again FWIW

@stale
Copy link

stale bot commented Sep 24, 2019

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Sep 24, 2019
@stale stale bot closed this as completed Oct 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants