Feat: Automate sync_translations workflow for 30 minute delays#20758
Feat: Automate sync_translations workflow for 30 minute delays#20758LUwUcifer wants to merge 1 commit intoankidroid:mainfrom
Conversation
|
Requesting Review from @mikehardy |
| core.setOutput('time_left', timeLeft); | ||
|
|
||
| - name: Sleep until completion | ||
| if: steps.calc_time.outputs.time_left > 0 |
There was a problem hiding this comment.
Let me know if I should remove the redundant time check, i implemented it here because calc_time seems prone to mutability
| env: | ||
| GH_TOKEN: ${{ secrets.MACHINE_ACCOUNT_PAT }} | ||
| run: | | ||
| OUTPUT=$(gh run list --workflow sync_translations.yml --json startedAt | jq -r '.[1].startedAt') |
There was a problem hiding this comment.
Why started? There's a 30 minute API cool down, and a faster execution on round 2 would still hit a rate limit
There was a problem hiding this comment.
My bad, updated the code to reflect the latest state
There was a problem hiding this comment.
There's a 30 minute API cool down
The API isnt used until yarn build no? 30 min sleep before should work as intended
LUwUcifer
force-pushed
the
schedule-translations-sync
branch
2 times, most recently
from
95326ed to
8b6f6c2
Compare
mikehardy
left a comment
mikehardy
left a comment
There was a problem hiding this comment.
interesting - I really like the approach of interrogating the github API to determine workflow run history - but I'm not so sure on the details of the implementation - seems really close though
| env: | ||
| GH_TOKEN: ${{ secrets.MACHINE_ACCOUNT_PAT }} | ||
| run: | | ||
| OUTPUT=$(gh run list --workflow sync_translations.yml --json updatedAt | jq -r '.[1].updatedAt') |
There was a problem hiding this comment.
we only want runs that succeeded or failed I think, and should filter out runs that were cancelled, it is possible that the latest run started, and then because of the concurrency group set to cancel in progress above takes effect - a previous run was cancelled and now we get a last updated timestamp that was just before this run...but crowdin API cooldown has on relation to that sequence of events
crowdin API cooldown only cares about runs that actually hit the API (and then either succeeded or failed), thus my thought that cancelled runs should be filtered out
There was a problem hiding this comment.
In that scenario we have to consider that the run cancelled from concurrency 'hit the api' before being cancelled, it would fail the new workflow if filtered out
LUwUcifer
force-pushed
the
schedule-translations-sync
branch
from
8b6f6c2 to
d8a75b7
Compare
|
the gh command was extrapolated from various doc pages like this, should I add comments breaking the command down? |
3 participants
Note
A new github environment key by the name of LATEST_RUN must be created for this to function
Purpose / Description
30 minute delays are necessary between every sync translation workflow run, requiring manual oversight
Fixes
Sync translationsaction to run 30 minutes after the last one. #19994Approach
How Has This Been Tested?
The functionality of these commands have been tested exclusively on a repository explicitly created for this
Sleep Function has proven to work as intended
Links to blog posts, patterns, libraries or addons used to solve this problem
Checklist
Please, go through these checks before submitting the PR.