Question: Need expert to vet my workflow using this Action & Feature Request: remove-stale-when-updated for issue/PR

[pllim]

Hello. I am sorry if I am abusing Issues like this, but I don't see any Discussions set up for this repo and I am unable to understand all nuances of the available features by just looking at README. I am in the process of moving a home grown stale bot to Actions, and I think this should do what I want but I am not 100% sure.

on:
  schedule:
    # runs every Wednesday at 1am UTC
    - cron: '0 1 * * 3'

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/stale@v3
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        operations-per-run: 50
        ascending: true

        days-before-issue-stale: -1
        days-before-issue-close: 7
        remove-issue-stale-when-updated: false
        stale-issue-message: 'This issue was labeled as **Close?**. Remove **Close?** label or this will be closed in 7 days.'
        close-issue-message: 'I am going to close this issue because it was marked with **Close?**, but if you feel that this issue should stay open, then feel free to re-open, remove **Close?** and **closed-by-bot** labels, and apply **keep-open** label.'
        close-issue-label: 'closed-by-bot'
        exempt-issue-labels: 'keep-open'
        only-issue-labels: 'Close?'

        days-before-pr-stale: 150
        days-before-pr-close: 30
        remove-pr-stale-when-updated: true
        stale-pr-message: 'This pull request is stale because it has been open 150 days with no activity. Remove **Close?**, comment, or push, or this will be closed in 30 days.'
        close-pr-message: 'I am going to close this pull request as per my previous message, but if you feel that this issue should stay open, then feel free to re-open, remove **Close?** and **closed-by-bot** labels, and apply **keep-open** label.'
        stale-pr-label: 'Close?'
        close-pr-label: 'closed-by-bot'
        exempt-pr-labels: 'keep-open'

I am thinking having it run weekly, going through the 50 oldest stuff first (hence, ascending: true).

Desired issue handling:

• Only comb through open issues marked as "Close?" and then issue stale-issue-message and start the clock. Skip issues with "keep-open" label.
• People commenting on the issue will not reset the clock.
• After 7 days (this is separate from the cron setting, though is coincidentally also weekly), issue close-issue-message, slap a "closed-by-bot" label, and close the issue.

Desired pull request handling:

• Comb through open PRs, except those with "keep-open" label.
• For those without activity the last 5 months or so (150 days), issue stale-pr-message, slap a "Close?" label, and start the clock.
• People commenting or pushing new commits will reset the clock. (Though currently, we don't let comments reset the clock but it is a small change that we can live with, I think.)
• After another month or so (30 days), issue close-pr-message, slap a "closed-by-bot" label, and close the PR.

Things I am not sure about using this Action:

1. I am not sure if the YAML is really what my desired issue handling logic is. Is the desired issue logic even possible with this Action? In the home grown bot, it checked for the presence of stale-issue-message and that's how it knows whether to proceed with close-issue-message or not. I don't know what is the equivalent logic here. If you don't have something like this, what is the closest logic that I can use?
2. Currently, you only have remove-stale-when-updated but I think I need different settings for issue and PR, respectively; hence, the feature request.

I really like what you have done here and wish to use this Action if possible. Thank you for your contributions to the FOSS community!

[C0ZEN]

@pllim adding a label as stale by hand is quite experimental or should I say not the usual way.
If you encounter issues, please let us know.
But I do not mean it like "do not do it".
More like "do it and let's improve if needed".

For information, I can already tell you that the stale message will not be added to the issue if you add the label manually.
It's an improvement that we talked not long ago but it's not yet implemented.

I think that you should change the cron to run daily (to respect at one day close the warning messages about stale/close).

BTW I think I found an issue based on the code: the option remove-stale-when-updated should remove the stale label when a comment is added but also when there is an update on the issue (a change of label, milestone, assignee, that kind of stuff that GitHub consider a change) and for the second case, we simply don't remove the stale label, we only avoid to close. @hross any feedback is welcome, dunno if it's a feature or not. Below the culprit.

People commenting or pushing new commits will reset the clock. (Though currently, we don't let comments reset the clock but it is a small change that we can live with, I think.)

So based on what I understand, it's more:

People commenting will reset the clock.

const issueHasUpdate: boolean = IssuesProcessor._updatedSince(
  issue.updated_at,
  daysBeforeClose
);
issueLogger.info(`$$type has been updated: ${issueHasUpdate}`);

// should we un-stale this issue?
if (this.options.removeStaleWhenUpdated && issueHasComments) {
  await this._removeStaleLabel(issue, staleLabel);
}

I agree that we need to improve the option remove-stale-when-updated to have a different behaviour based on issue or PR and I will create an issue for that.

The rest is good based on what you needs IMO but eventually you will find out by yourself once the action is running ;)

[pllim]

Thanks for the quick and thoughtful replies! I'll ponder on this for a bit, as I am not beyond modifying our existing process either.

[C0ZEN]

@pllim if you want to play it safe, maybe you can still create and merge your action configuration (with a daily cron?) and set debug-only: true so it will run as dry-run and enable the logs as well so you will be able to understand a bit more what's under the hook if it can reassure you.

[C0ZEN]

And the PR for the new options #383

[pllim]

I think I have a better understanding now. Thanks! Looking forward to #380 and #383 .