Add workflows to ping about play reviews #7177

keunes · 2024-05-10T14:22:51Z

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 · 2024-05-10T19:57:37Z

.github/workflows/release-actions.yml

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


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.

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

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

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 · 2024-05-11T08:16:34Z

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 · 2024-05-18T17:46:24Z

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 · 2024-05-18T19:47:25Z

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 · 2024-05-20T19:50:39Z

Sounds good

ByteHamster · 2024-06-09T17:11:09Z

scripts/getChangelog.py

+      })
+
+  # Create a list of dictionaries with commits for in CSV file
+      # /// NOTE maybe it's better to move this up to before the PR list generation (but after the list of unique PRs has been created) as it clears some of the memory used


I don't think we need to care about memory here. To fill gigabytes of RAM on a PC, you need a lot of PRs.

ByteHamster · 2024-06-09T17:12:20Z

scripts/getChangelog.py

+# Define variables
+owner = os.getenv('OWNER', "AntennaPod") # The owner (organisation or user) of the repository
+repo = os.getenv('REPO', "AntennaPod") # The repository name
+token = os.getenv('GITHUB_API_TOKEN') # The GitHub API token [evnironment variable, otherwise user input]


Nice, doing this via an environment variable avoids having to re-type the api token every time

ByteHamster · 2024-06-09T17:12:49Z

scripts/getChangelog.py

+base_ref = os.getenv('BASE') # The base reference (release code or branch); point of reference [user input]
+head_ref = os.getenv('HEAD') # The head reference (release code or branch); environment containing the changes [user input]


If this is always user input, I don't think it needs to be read from the environment variables

ByteHamster · 2024-06-09T17:13:32Z

scripts/getChangelog.py

+owner = os.getenv('OWNER', "AntennaPod") # The owner (organisation or user) of the repository
+repo = os.getenv('REPO', "AntennaPod") # The repository name


Can't we hard-code this instead of using a variable? That would maybe reduce the complexity of the code a bit.

ByteHamster · 2024-06-09T17:15:20Z

scripts/getChangelog.py

+token = os.getenv('GITHUB_API_TOKEN') # The GitHub API token [evnironment variable, otherwise user input]
+base_ref = os.getenv('BASE') # The base reference (release code or branch); point of reference [user input]
+head_ref = os.getenv('HEAD') # The head reference (release code or branch); environment containing the changes [user input]
+max_associatedPRs = 5 # The maximum number of pull requests that the script will fetch per commit


I would move this closer to where it is used. Makes it easier to read

ByteHamster · 2024-06-09T17:18:13Z

scripts/getChangelog.py

+            If you're using bash or zsh, you can add the following line to your shell profile file (.bashrc, .bash_profile or .zshrc):
+            export GITHUB_API_TOKEN='{token}'
+
+            If you're using Fish shell, you can add the following line to your config.fish file:
+            set -x GITHUB_API_TOKEN '{token}'
+
+            After adding this line, you'll need to restart your terminal or run 'source ~/.bashrc' (or the appropriate file for your shell) for the changes to take effect.
+
+            On Windows, you can set environment variables through the System Properties. Here's how:
+            1. Right-click on Computer on the desktop or in the Start menu.
+            2. Choose Properties.
+            3. Click on Advanced system settings.
+            4. Click on Environment Variables.
+            5. Click on New under the User or System variables sections.
+            6. Enter 'GITHUB_API_TOKEN' as the variable name and '{token}' as the variable value.
+            7. Click OK in all windows.
+


Do we really need this tutorial in our changelog script? I think users of this script can google themselves how to set an environment variable. This again reduces the length/complexity of the script.

ByteHamster · 2024-06-09T17:20:08Z

scripts/getChangelog.py

+
+  # Define head_ref
+  if not head_ref:
+    print("\nThen, from which environment would you like to see the changes (the head)?")


I don't understand environment here. Maybe just "where do you want the changes to start`?

ByteHamster · 2024-06-09T17:21:54Z

scripts/getChangelog.py

+      # Create string with issue & PR number(s) that need review replies
+      numbers = []
+      maximum_hit = False
+      if any(label['id'] == 'LA_kwDOAFAGHc8AAAABoGK6aw' for label in prdata['labels']['nodes']):


Can this be done based on the label name instead of label id? That would make it easier to read

ByteHamster · 2024-06-09T17:23:52Z

.github/workflows/release-actions.yml

+  comment:
+    runs-on: ubuntu-latest
+    steps:
+      - name: "Tag review replyers in closed issues with 'Needs: Review reply' label"


This workflow is no longer needed, right? Now that the script checks it

Add workflows to ping about play reviews

d455323

keunes requested a review from ByteHamster May 10, 2024 14:22

keunes added the Area: Project issue label May 10, 2024

ByteHamster reviewed May 10, 2024

View reviewed changes

Rewrite getChangelog.py in GraphQL

56e8a3b

ByteHamster reviewed Jun 9, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add workflows to ping about play reviews #7177

Add workflows to ping about play reviews #7177

keunes commented May 10, 2024

ByteHamster May 10, 2024

keunes May 10, 2024 •

edited

ByteHamster May 11, 2024 •

edited

keunes May 11, 2024

keunes commented May 11, 2024

ByteHamster commented May 18, 2024 •

edited

keunes commented May 18, 2024

ByteHamster commented May 20, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

ByteHamster Jun 9, 2024

		base_ref = os.getenv('BASE') # The base reference (release code or branch); point of reference [user input]
		head_ref = os.getenv('HEAD') # The head reference (release code or branch); environment containing the changes [user input]

		owner = os.getenv('OWNER', "AntennaPod") # The owner (organisation or user) of the repository
		repo = os.getenv('REPO', "AntennaPod") # The repository name

Add workflows to ping about play reviews #7177

Are you sure you want to change the base?

Add workflows to ping about play reviews #7177

Conversation

keunes commented May 10, 2024

Description

Checklist

Choose a reason for hiding this comment

keunes May 10, 2024 • edited

Choose a reason for hiding this comment

ByteHamster May 11, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

keunes commented May 11, 2024

ByteHamster commented May 18, 2024 • edited

keunes commented May 18, 2024

ByteHamster commented May 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

keunes May 10, 2024 •

edited

ByteHamster May 11, 2024 •

edited

ByteHamster commented May 18, 2024 •

edited