Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems since moving to v5 - action takes bot comment as a regular update #795

Closed
derberg opened this issue Aug 16, 2022 · 12 comments · Fixed by #816
Closed

Problems since moving to v5 - action takes bot comment as a regular update #795

derberg opened this issue Aug 16, 2022 · 12 comments · Fixed by #816
Labels
bug Something isn't working

Comments

@derberg
Copy link

derberg commented Aug 16, 2022

Your stale action configuration

Config here -> https://github.com/asyncapi/bundler/blob/master/.github/workflows/stale-issues-prs.yml

name: Manage stale issues and PRs

on:
  schedule:
  - cron: "0 0 * * *"

jobs:
  stale:
    if: startsWith(github.repository, 'asyncapi/')
    name: Mark issue or PR as stale
    runs-on: ubuntu-latest
    steps:
    - uses: actions/[email protected]
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-issue-message: |
          This issue has been automatically marked as stale because it has not had recent activity :sleeping:

          It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation. 

          There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under [open governance model](https://github.com/asyncapi/community/blob/master/CHARTER.md). 

          Let us figure out together how to push this issue forward. Connect with us through [one of many communication channels](https://github.com/asyncapi/community/issues/1) we established here.

          Thank you for your patience :heart:
        stale-pr-message: |
          This pull request has been automatically marked as stale because it has not had recent activity :sleeping:

          It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation.

          There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under [open governance model](https://github.com/asyncapi/community/blob/master/CHARTER.md). 

          Let us figure out together how to push this pull request forward. Connect with us through [one of many communication channels](https://github.com/asyncapi/community/issues/1) we established here.

          Thank you for your patience :heart:
        days-before-stale: 120
        days-before-close: 120
        stale-issue-label: stale
        stale-pr-label: stale
        exempt-issue-labels: keep-open
        exempt-pr-labels: keep-open
        close-issue-reason: not_planned```

Further context

One of examples is this issue -> asyncapi/bundler#34
We run stale action every day.
So one day issue got stale label and comment from bot: https://github.com/asyncapi/bundler/runs/7602251973?check_suite_focus=true
But then, next day, it was "unstaled" with https://github.com/asyncapi/bundler/runs/7622201096?check_suite_focus=true

See the logs:

Checking for comments on issue since: 2022-08-01T00:00:42Z
Comments that are not the stale comment or another bot: 0
The stale label should not be removed
Remove the stale label since the issue has been updated and the workflow should remove the stale label when updated

I can't figure why it decided all suddenly to remove stale label.

Another example, from completely different repo, but with exactly the same configuration -> asyncapi/website#659 (comment)

Issues noticed after moving from v4.0.0 to v5.1.0

@derberg derberg added the bug Something isn't working label Aug 16, 2022
@rooterkyberian
Copy link

I have a similar issue, but my scenario is somewhat niche.
Since my billing plan doesn't allow running github actions natively I run them through https://github.com/nektos/act locally.
This is where I run in exactly the same problem as OP.

Would be nice if I could ignore updated from a particular user (which I use to run this action), instead of being hardcoded.

I acknowledge this may not be the scenario which you want to optimize the tool for, but if its would be just about exposing a configuration option instead of hardcoding something in then maybe it would be worthy addition?

@ghogen
Copy link

ghogen commented Sep 1, 2022

This is a totally blocking issue for us in the docs platform. We're forced to revert to the earlier version.

dcshzj added a commit to dcshzj/RepoSense that referenced this issue Sep 5, 2022
The actions/stale GitHub Actions v5 has an issue where updates by the
GitHub Actions bot are recognized as updates. This causes the bot to not
work as intended as the Stale label will be removed.

This issue has already been reported at:
actions/stale#795

Let's downgrade the actions/stale package to v4 until the bug has been
fixed upstream.
@luketomlinson
Copy link
Collaborator

@derberg Can you try version 5.1.1 (or just @v5)? There was a bug in 5.1.0.

@luketomlinson
Copy link
Collaborator

@ghogen Can you confirm which version of stale you are on? v5.1.0 has this bug.

dcshzj added a commit to reposense/RepoSense that referenced this issue Sep 8, 2022
The actions/stale GitHub Actions v5 has an issue where updates by the
GitHub Actions bot are recognized as updates. This causes the bot to not
work as intended as the Stale label will be removed.

This issue has already been reported at:
actions/stale#795

Let's downgrade the actions/stale package to v4 until the bug has been
fixed upstream.
@ghogen
Copy link

ghogen commented Sep 8, 2022

@luketomlinson
We upgraded to 5.1.0 and then about a week later, upgraded to 5.1.1.
Then after reading the issue, we just recently reverted back to v4.
I'm upgrading again to 5.1.1 and we'll see if we have any further problems, thanks

@ghogen
Copy link

ghogen commented Sep 8, 2022

@luketomlinson
Looking more closely, no, there is still something not right here. Here's the log from a run we did with 5.1.1.
image

Line 1847 is correct - stale should not be removed
Line 1849 says the opposite, but it is not correct - the issue was not updated so it should not be removing the stale label - the only change was that the stale label was applied and the bot comment was added, so this is resetting the update clock I think

The issue is https://github.com/MicrosoftDocs/visualstudio-docs/issues/7515

@ghogen
Copy link

ghogen commented Sep 8, 2022

The test that leads to incorrect result that "Issue has been updated since it was marked stale" is the following from line 741 of index.js:

const issueHasUpdateSinceStale = new Date(issue.updated_at) > new Date(markedStaleOn);

We know the value of "markedStaleOn" as it is printed in the log 2022-07-14T00:14:00Z. The issue updated date is also printed at the top of the log screenshot 2022-07-14T00:14:01Z, and it differs by one second. The test returned "true" because the timestamp slightly differs between those two Date objects, even though they represent the same "update" (the application of the stale label).

Suggested fix: Change the test to check if the absolute value of the difference between the two Date objects is greater than 1 minute.

@luketomlinson
Copy link
Collaborator

Great find @ghogen! I just merged a PR to fix it. If you're so inclined, you can try pointing your action to @actions/stale@main to see if it fixes the issue.

@derberg
Copy link
Author

derberg commented Sep 12, 2022

@luketomlinson, when do you plan to release?

@luketomlinson
Copy link
Collaborator

@derberg done! https://github.com/actions/stale/releases/tag/v5.2.0 (the v5 tag is also updated, so no action needed if you are using that)

@ghogen
Copy link

ghogen commented Sep 23, 2022

We're looking at the newer activity of the bot and still seeing that the bot's own prior activity (adding comments, adding or removing labels) is still counted as activity on the issue. This is unrelated to the timestamp comparison problem, but it matches the original title of this issue. I'm using "v5" which should pick up the 5.2.0 which I think should have the update. Here's an issue that we processed through the latest version and it decides that the "last updated date" is 9/15/2022 which is when it removed the stale label. The last real update was back in March.
image

https://github.com/MicrosoftDocs/visualstudio-docs/issues/6077
We have two other examples all with the same problem.

@ghogen
Copy link

ghogen commented Sep 23, 2022

@luketomlinson Honestly, I don't see in the logic in processIssues where it supposedly filters out its own activity to measure the last updated date. It looks to me like it just takes "updated_at" from the GitHub API and so where is the intelligence to ignore its own activity?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants