3.0.4 - Activity does not remove STALE flag

[william76]

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/stale@v3.0.4
      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

[fjeremic]

Looking at the source code here is the logic which dictates whether the stale label should be removed:

stale/src/IssueProcessor.ts

Lines 210 to 216 in b6f9559

	// should we un-stale this issue?
	if (this.options.removeStaleWhenUpdated && issueHasComments) {
	core.info(
	`Issue #${issue.number} is no longer stale. Removing stale label.`
	);
	await this.removeLabel(issue, staleLabel);
	}

From the above snippet it relies on the logic here:

stale/src/IssueProcessor.ts

Lines 251 to 255 in b6f9559

	const filteredComments = comments.filter(
	comment =>
	comment.user.type === 'User' &&
	comment.user.login !== github.context.actor
	);

Note that the "updated" comments are filtered to those not made by either a bot, or the user which triggered the action. Since you are the owner of that repository the action runs under your user context. You can see this in the debug output above:

Comments not made by william76 or another bot: 0

This means the action is counting no new comments and it does not remove the stale label. This is by intention. To show that the action should remove the stale label if some other user comments I've gone ahead and added a comment in william76/workflowTest#1. @william76 if you can trigger the bot again we can test if the stale label will be removed.

[william76]

@fjeremic Ah, ok. I triggered the workflow on that issue and it removed the STALE flag on my test issue...

So to clarify what you're saying... The bot will only clear the STALE label if the user that makes the comment is not the same as who 'triggered' the bot?

I'm pretty new to exploring workflows in GitHub and don't quite follow what counts as the user that triggered the action. Is it just because I own the repo so anytime it's triggered it's considered to run under my context?

Is there a way to change what 'user' it's running as? or would the workflow always essentially run as me?

Would it be possible for the workflow to have a setting that would change this behavior so that it ignores activity by the bot but does not ignore activity by the repo owner?

[fjeremic]

So to clarify what you're saying... The bot will only clear the STALE label if the user that makes the comment is not the same as who 'triggered' the bot?

That's right.

Is it just because I own the repo so anytime it's triggered it's considered to run under my context?

That's also correct.

Is there a way to change what 'user' it's running as?
Would it be possible for the workflow to have a setting that would change this behavior so that it ignores activity by the bot but does not ignore activity by the repo owner?

As far as I know, no there is no way to change that. The code in question was introduced in #73 to fix a valid problem.

[william76]

Thanks for the quick responses! I really appreciate the assistance 😄

I saw that happening in #18 where the bot would put the stale label on and then remove it... I'm not sure that the right approach is to make the bot ignore any changes made by the owner of the repository though. To me that's really an unexpected behavior. If I set a workflow on a repository that I own... I don't expect it to ignore my contributions.

I suppose the workaround could be to create an entity account on Github and make the workflow use that entity accounts token but Github used to disallow 2nd accounts. This may have changed since MSFT took them over though, I haven't looked at those policies in the past year or two. I can try it and see if that does anything. That policy was really annoying to me in the past since it makes more sense to have a personal account for my personal stuff and a work account for my work-related activities.

In any case, I imagine this kind of workflow isn't really targeted at a single user repo but rather more for a larger team... which is exactly what I'm evaluating it for. We have a project with > 100 developers and about 6.5M lines of code and > 1k issues and we're looking into workflows that could take care of some of the administrivia such as dealing with abandoned issues :p If the solution is to just have the workflow run off an entity then that could be something we can use... but I will have to test it on my test repo 😄

[fjeremic]

Perhaps @hross can shed some light under which user context cron actions run on. It doesn't seem clear cut to me looking at the actions in the eclipse/omr repo. It seems it runs under different user contexts, all of whom have write access to the repository. I'm not sure how exactly it is decided though.

[hross]

The user who last committed the cron schedule will be the user who the github context runs as. Unfortunately, at this time we don't have a better association method so if you're doing this as "yourself" you have three options:

• run the action as "you" and you will not get the un-staling feature
• turn off un-staling (this will revert to the previous behavior where nothing gets un-staled -- although I think this is the worst option)
• use an alternate account to commit the cron change which does not participate in the repo

Hope that helps @fjeremic @william76

I am going to close this issue since I don't think there is any action on the stale side (but let me know if there is something we need to address).

[william76]

@hross ok. I will add that this behavior seems quite odd to me -- that one needs to know that they must use an alternate account (which used to violate GitHub TOS) to make the commit to the workflow file since that dictates who GitHub runs the workflow as, or it won't remove the stale flag is really nonobvious to me and smells like a huge side-effect. It may be an obvious thing to those who work with GitHub workflows alot, but for people like myself who are starting an evaluation of them it's not.

I would ask that you guys clearly document this in your README.md file. My initial reporting of this workflow to my project leads is that it is unstable and isn't worth pursuing any further. Normally that would be it, so I'm glad I put in this issue as it's been informative. I will test the workflow again with a separate 'bot' account to see what happens and update my assessment to my team leads if it works out.

Thanks for the responses :)

[daleharvey]

I would +1 that this is extremely confusing behaviour

However also seeing the stale label not removed on issues where people other than myself have commented such as pouchdb/pouchdb#8196