[MPDX-8446] Automate translation download and extraction

[canac]

Description

• On every commit to main run yarn extract before uploading labels to OneSky. That way translation can begin immediately on any new labels instead of needing to wait for public/locales/en/translation.json to be updated. (The extracted labels are not committed and are discarded when the action terminates)
• During deployment to Amplify, run yarn onesky:download to deploy the app with the latest labels from OneSky. I tested that if that command fails for any reason, the deployment will still continue successfully.
  • I added the ONESKY_* environment variables to Amplify.
• Add a new workflow that runs daily to create a PR with any new labels from yarn extract or yarn onesky:download. Here is an example from my fork of the PR that will be created: [no-Jira] Update translations canac/mpdx-react#5. If the PR hasn't merged, the action will rebase and force-push any new labels to the branch.

MPDX-8446

Checklist:

• I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
• I have applied the appropriate labels. (Add the label "On Staging" to get the branch automatically merged into staging.)
• I have requested a review from another person on the project

[github-actions]

Bundle sizes [mpdx-react]

Compared against 34edc48

No significant changes found

[github-actions]

Preview branch generated at https://8446-automate-translations.d3dytjb8adxkk5.amplifyapp.com

[wrandall22]

I tested that if that command fails for any reason, the deployment will still continue successfully.

Have we tested what happens when we get a timeout from OneSky?

[canac]

Have we tested what happens when we get a timeout from OneSky?

@wrandall22 Not specifically. I tested the case where the environment variables aren't provided and it logs a 401 message and terminates with a successful error code. Are you afraid of it hanging forever if OneSky doesn't respond?

[wrandall22]

Right, my concern would be it hanging forever or making the deployment timeout.

[canac]

Right, my concern would be it hanging forever or making the deployment timeout.

@wrandall22 OK, I set it up to timeout after one minute. It takes 10 seconds to run locally on my machine, so that should be plenty of time. I tested in a branch that timeout 1s sleep 5 || echo "Timed out" prints the message and doesn't stop the deployment.

[dr-bizz]

This is looking great! I left some comments

[dr-bizz]

Do we want to add reviewers to this?

[dr-bizz]

What are your thoughts about adding delete-branch: true to delete thre branch after each merge and so the branch is only around if changes are to be made.

[canac]

What are your thoughts about adding delete-branch: true to delete thre branch after each merge and so the branch is only around if changes are to be made.

We have this repo configured to automatically delete branches from merged PRs, so that shouldn't be an issue

[canac]

Do we want to add reviewers to this?

Adding team reviewers requires a Personal Access Token with repo scope or making a GitHub App with those permissions (https://github.com/peter-evans/create-pull-request/tree/v7/#action-inputs). If we use a PAT, we have to deal with rotating it when it expires and having to get someone else to create one if the person who created it leaves our GitHub org or the web-engineering-js team. It's also less secure to use a long-lived PAT instead of the short-lived automatic GITHUB_TOKEN. Making a GitHub App for this also doesn't feel worth it.

If the goal is to be alerted when this PR gets created, I think we can mention @CruGlobal/web-engineering-js in the PR body, and we'll all get a notification.

[dr-bizz]

Thank you for making this! Lets test it out and review after some time

[canac]

Lets test it out and review after some time

@dr-bizz Yes, it would be good to revisit this maybe in the new year to see if we would like to make any adjustments.