[SAME VERSION] Workflow to mark inactive issues/PRs as stale and eventually close them

[romoh]

What this PR does / why we need it:
Help keeping akri repo current by marking issues and PRs with no recent activity as stale and eventually closing them.

Special notes for your reviewer:

If applicable:

• this PR has an associated PR with documentation in akri-docs
• this PR contains unit tests
• added code adheres to standard Rust formatting (cargo fmt)
• code builds properly (cargo build)
• code is free of common mistakes (cargo clippy)
• all Akri tests succeed (cargo test)
• inline documentation builds (cargo doc)
• version has been updated appropriately (./version.sh)

[bfjelds]

just to double check ... does {secrets.GHTOKEN} have any issue with PRs from forks?

[romoh]

Shouldn't be a problem. The token should have enough permissions to add labels, add comments and close PR.

[bfjelds]

my curiousity was more around whether a forked pr would have access to secrets. i think it is ok, but wanted to make sure we tried it.

[kate-goldenring]

Curious: Does day 1 on the stale check start when this is merged or will issues that have already been inactive for 45 days be marked stale? Also, does triaging actions count as "activity" and would remove stale? Or just comments? The latter is probably preferred IMO.

[bfjelds]

Curious: Does day 1 on the stale check start when this is merged or will issues that have already been inactive for 45 days be marked stale? Also, does triaging actions count as "activity" and would remove stale? Or just comments? The latter is probably preferred IMO.

i think the time is dictated by the issue's updated_at state (which reflects the last time the issue was updated) against now. we will probably see a lot of issues that are summarily marked stale instantly. triaging should be activity, as updated_at is changed by just about everything.

[romoh]

Curious: Does day 1 on the stale check start when this is merged or will issues that have already been inactive for 45 days be marked stale? Also, does triaging actions count as "activity" and would remove stale? Or just comments? The latter is probably preferred IMO.

i think the time is dictated by the issue's updated_at state (which reflects the last time the issue was updated) against now. we will probably see a lot of issues that are summarily marked stale instantly. triaging should be activity, as updated_at is changed by just about everything.

Brian is correct (see my earlier reply to Jirka)
The action is based off the issue's updated_at field and uses that for calculations. Any updates to the issue resets the counter.

Brian, for your concern I was planning on adding keep-alive for good first issues before merging. That way those issues are not marked as stale. Also since @kate-goldenring did recent cleanup most issues have been recently updated so we shouldn't see a flood of stales after merge.

[jiria]

Brian, for your concern I was planning on adding keep-alive for good first issues before merging.

Great idea. Should we expand it to issues that were not triaged yet? Or more generically, have a label to denote issues that await feedback from Akri team?

[romoh]

Brian, for your concern I was planning on adding keep-alive for good first issues before merging.

Great idea. Should we expand it to issues that were not triaged yet? Or more generically, have a label to denote issues that await feedback from Akri team?

Good point, We can also exclude untriaged issues, but right now we don't have any labels for those.
Looks like a potential improvement: Label any newly created issue as untriaged so that we can exclude it from stale issue rules. Having said that, we triage monthly so 45 days should be more than enough to cover new issues.