-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add workflows to ping about play reviews #7177
base: develop
Are you sure you want to change the base?
Conversation
owner: context.repo.owner, | ||
repo: context.repo.repo, | ||
issue_number: issue.number, | ||
body: 'This feature or fix is now released! @AntennaPod/review-replyers, time to inform relevant reviews in Google Play console (please see links in one or more of the comments above).' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think this part is quite hard to do. We often close issues on the develop branch after the feature freeze of the beta version. So this would tag things that are not actually released.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking a look.
This workflow only runs when you create a public release (see line 4), i.e. when it's available on Google Play. Only at that point it posts messages on closed issues (thus not as soon as the issue gets closed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup but when creating the release, we have already closed additional issues that are not in that release but the release after that
For example, "download without subscribing" is closed but will be in 3.5.0, not 3.4.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's what you mean. Right.
Then either we should start linking issues with milestones, or I get tagged twice on some issues (which is not a huge problem).
Actually, I just thought of another approach to get the list of issues/PRs which are actually included in the release: replicate a process like in https://github.com/AntennaPod/AntennaPod/blob/develop/scripts%2FgetChangelog.py |
Yeah, using that script sounds more reliable. Maybe it could even just add a column to the changelog output checking if the issue in the PR description contains a review? |
Hmm, that might be an idea. We could apply the label at issue level still, and then check for that. Otherwise we'd have to cycle through all comments in the script, and there's already a delay to not hit the rate limit. |
Sounds good |
Description
Set up two workflows to:
Once replied, the user should remove the label in order to avoid being tagged again.
For this to work, I have also set up the 'review-replyers' team, which when tagged should ping all team members (currently only me).
Checklist
./gradlew checkstyle spotbugsPlayDebug spotbugsDebug :app:lintPlayDebug