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

Workflow to label and comment stale pull requests #13522

Merged
merged 1 commit into from Sep 22, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
39 changes: 39 additions & 0 deletions .github/workflows/stale-pull-requests.yml
@@ -0,0 +1,39 @@
name: Check stale pull requests

on:
workflow_dispatch:
schedule:
- cron: '0 12 * * *'

permissions:
issues: read
pull-requests: write

env:
BEFORE_STALE: 14
BEFORE_CLOSE: 7

jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v5
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The action is producing this warning:

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Do they have a newer version that does not use set-output already?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they released v6 some days ago which already upgrade to the new format: actions/stale#839

with:
debug-only: true
# disable issues
days-before-issue-stale: -1
days-before-issue-close: -1
stale-pr-message: |
This pull request is stale because it has been open for ${{ env.BEFORE_STALE }} days with no activity.
It will be closed in ${{ env.BEFORE_CLOSE }} days unless the `stale` label is removed.
close-pr-message: |
This pull request was closed due to a lack of activity for ${{ env.BEFORE_CLOSE }} days after it was stale.
stale-pr-label: stale
close-pr-label: closed-due-inactivity
Comment on lines +31 to +32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remember to actually create these labels before we run the bot. Github would create them automatically but without colors or description.

days-before-pr-stale: ${{ env.BEFORE_STALE }}
days-before-pr-close: ${{ env.BEFORE_CLOSE }}
exempt-pr-labels: 'external contribution'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This label actually has an emoji in it :) It should be external contribution :star:.

exempt-draft-pr: true
exempt-all-milestones: true
remove-stale-when-updated: true
operations-per-run: 60
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd increase this to 100 so that we can process all our current PRs in one go.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. But for some reason, this action is parsing issues even though we explicitly disable it. I'm thinking of using another one that I did in my tests that call the graphql api directly for the PRs instead of use this actions/stale, but it is still a bit incomplete (it does not do everything that the actions/stale does yet).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. It probably fetches from the API first and filters only then. Might be worth a feature request or something.

I'd keep it simple for now and stick to this action but yeah, in the longer term we might actually want to switch to the other one (or build a custom one) because I think that just marking as stale is not what we want in some cases. E.g. for unreviewed PRs we might want to instead assign someone randomly or ping the channel or something.