feat: different stale timers based on tags

[casswedson]

Summary

None

Purpose of change

implement an idea from fris in the discord

this achieves different stale timers by

• use any-of-labels to filter for one set of tags only [suggestions] and filter exempt labels after, stale timer is 15 days and 15 after to close.

• duplicate the job and filter for [needs confirmation] and so we don't ignore PRs search for json-styled and astyled - filter exempt labels after, stale timer is 30 days and 30 to close

this is a little dirty hack cause there are situations where PRs don't get applied any 'styled' tag, I think this is a worthwhile trade

Describe the solution

Describe alternatives you've considered

Testing

Additional context

[kevingranade]

One technical note, this workflow makes a lot of API calls, I already have it split into ascending and descending on alternating hours in order to get maximum coverage (it doesn't consistently meet in the middle even then). If we're dding more invocations of it, they need to proceed in a 3-4 hour cycle to limit impact.
Implementation wise, you can possibly have the two workflows exit early in their get-time steps on alternating hours, then adjust the check in the "ascending" property to be a different sequence of numbers.

Can you expand on what "and filter for [needs confirmation] and so we don't ignore PRs search for json-styled and astyled" means? Why filter for Needs Confirmation at all?

It's fine for the two jobs to not operate on a proper partition of the issues, if they fall into the "suggestions / discussion" bucket they will be staled and closed sooner, and that does not change how issues without "suggestions / discussion" are handled.

[kevingranade]

I glanced at the stale action repo and they added a statefullness feature now that renders that other process unecessary, and in fact it looks like my workaround is sabotaging the new feature, so I need to rip that out.

[kevingranade]

Based on some thoughts about interaction between the stale action cache and switching up workflows, I think what we want to do is have the short and long workflows run on alternating days or at least sizeable chunks of hours. I.e. long processing workflow runs for 6hrs in a row then short processing workflow runs for 6 hrs in a row. It doesn't really matter which as long as they run for enough hours in a row to process all the outstanding issues, which I think is about 4. On the other end of things, alternating days would also be fine, it would just result in staling and closing some issues one day late sometimes, which isn't a meaningful problem IMO.

[casswedson]

yeah, sorry this is a rough draft at best to point out that this sort of thing is possible, honestly I would like to leave this on your capable hands

[kevingranade]

Sure thing if I have time I'll look into polishing it up, it's a good idea I hadn't considered.

[Maleclypse]

I believe this can be closed now after the new stale actions were created but I'll wait to hear back on this.