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

chore(ci): revisit stale issues automation #1341

Merged
merged 6 commits into from
Feb 27, 2023

Conversation

dreamorosi
Copy link
Contributor

Description of your changes

As described in #1340, the current automation for stale issues was broken. While in the issue I incorrectly assumed that this was stalebot's fault, this was not the case.

The repo actually had two different automations for the same purpose: one was the aforementioned stalebot and the other was a workflow called stale-issues.yml that is run every day at midnight. The latter was the one that was broken.

Additionally, while looking into stalebot, I found out that it's now unmaintained and deprecated, so in this PR I am removing its configuration from the repo.

The stale workflow was previously running using the aws-actions/stale-issue-cleanup action, however after comparing it with the official actions/stale the differences were minimal and I decided to go with the official one.

As mentioned, the workflow is expected to run once a day at midnight. It's not clear which timezone this refers to, given that the cron feature doesn't support timezones, however based on previous executions this seems to be between midnight and 1AM CET, which is good enough.

The workflow operates only on issues and only on issues explicitly labeled as need-more-information and status/discussing. This should limit the amount of issues closed automatically given that maintainers should use these two labels in conjunction to denote that an issue is being discussed but more information is needed from the person who opened it.

If no interaction is made (aka the info that was missing is not provided), the workflow will mark the issue as stale and apply the status/pending-close-response-required label. The workflow will also leave a comment that says:

This issue has not received a response in 2 weeks. If you still think there is a problem, please leave a comment to avoid the issue from automatically closing.

If 7 more days pass, the issue will finally be closed as not_planned (close reason) and labeled as status/rejected, with a comment:

Greetings! We are closing this issue because it has been open a long time and hasn’t been updated in a while and may not be getting the attention it deserves. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to comment or reopen the issue.

If instead the issue is interacted with within a week, the label will be removed and the issue stops being stale.

Issues that haven't yet been triaged (labeled as triage) or that have a clear status as indicated by the labels: status/confirmed, status/blocked, status/on-hold, status/completed, are excluded by the automation and left open.

PRs should be excluded by this workflow. The documentation around this is a bit unclear, but based on a comment in the project's issue it seems that setting a negative amount of days to the PR config of the action avoids marking any PR as stale.

How to verify this change

Once merged, check that there are no issues in the workflow syntax. Then a day after check the workflow execution to see that there were no runtime errors.

Related issues, RFCs

Issue number: #1340

Checklist

  • My changes meet the tenets criteria
  • I have performed a self-review of my own code
  • I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding changes to the examples
  • My changes generate no new warnings
  • The code coverage hasn't decreased
  • I have added tests that prove my change is effective and works
  • New and existing unit tests pass locally and in Github Actions
  • Any dependent changes have been merged and published
  • The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

  • I have documented the migration process
  • I have added, implemented necessary warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@dreamorosi dreamorosi self-assigned this Feb 27, 2023
@dreamorosi dreamorosi linked an issue Feb 27, 2023 that may be closed by this pull request
2 tasks
@pull-request-size pull-request-size bot added the size/M PR between 30-99 LOC label Feb 27, 2023
@github-actions github-actions bot added the internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.) label Feb 27, 2023
@dreamorosi dreamorosi merged commit 487298f into main Feb 27, 2023
@dreamorosi dreamorosi deleted the 1340-maintenance-revisit-stalebot-config branch February 27, 2023 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.) size/M PR between 30-99 LOC
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Maintenance: revisit stalebot config
1 participant