Add workflows to ping about play reviews

[keunes]

Description

Set up two workflows to:

• Add the 'Needs: Review reply' to an issue in case an added or edited issue comment contains the old or the new links to Play store reviews in the Google Play Console.
• Add a comment tagging an organisation team on an issue when a new release is published if the issue a) is closed (assuming it's been implemented/addressed) and b) has the 'Needs: Review reply' label (assuming that there are links to Google Play reviews which need a reply.

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

• I have read the contribution guidelines: https://github.com/AntennaPod/AntennaPod/blob/develop/CONTRIBUTING.md#submit-a-pull-request
• I have performed a self-review of my code
• I have run the automated code checks using ./gradlew checkstyle spotbugsPlayDebug spotbugsDebug :app:lintPlayDebug
• My code follows the style guidelines of the AntennaPod project: https://github.com/AntennaPod/AntennaPod/wiki/Code-style
• I have mentioned the corresponding issue and the relevant keyword (e.g., "Closes: #xy") in the description (see https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
• If it is a core feature, I have added automated tests

[ByteHamster]

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.

[keunes]

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).

[ByteHamster]

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

[keunes]

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).

[keunes]

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

[ByteHamster]

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?

[keunes]

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.

[ByteHamster]

Sounds good