First draft of running the I18n Sync Down & Out periodically throughout the week. #36750
Conversation
| # make sure the server gets seeded with latest level content for the sync in. | ||
| # Note that the CI_ONLY_BUILD environment variable is necessary; the server is | ||
| # not set up to actually serve a version of the website, and it will fail to | ||
| # build correctly if not thus restricted. | ||
| 0 */4 * * * cd /home/ubuntu/code-dot-org && CI_ONLY_BUILD=true bundle exec ./bin/cronjob ./aws/ci_build >>/tmp/cronlog 2>&1 |
There was a problem hiding this comment.
Will this run if we're not on the staging branch? Notably, I'm worried about a situation where we run the sync on Tuesday, never switch back to the staging branch, then the Monday sync is several days out of date.
There was a problem hiding this comment.
oh, whoops I forgot to commit that change! One moment
There was a problem hiding this comment.
Ahh the continuous sync doesn't switch branches. That still means it won't be able to pull from staging if there are conflicting files but I guess that's just something to look out for.
There was a problem hiding this comment.
That's correct! The idea is that we progress through the branches like this:
- Start on staging branch. From here, we will run the CI build to update our sources files from staging latest, and also run the continuous sync to update our translation files from Crowdin.
- Sunday evening, we run the I18n sync, which switches us to the i18n sync branch. From here we can continue to run the continuous sync, but won't run the CI build.
- Once the sync PRs have been merged, we switch back to the staging branch, which now includes the latest sync changes.
There was a problem hiding this comment.
Thanks for the explanation! And of course the i18n down/out steps don't change any English files so the chance of conflict is low.
This ended up being a lot simpler than I expected!
Specifically, we ended up just needing to make a couple tweaks to how the server manages its branches. Previously, the server would create the i18n sync branches during the i18n sync and then switch back to staging so it could continue to build. This means we are effectively "rewinding" the state of the server after the i18n sync, which would cause problems if we attempt to do more syncs before merging the sync PRs.
What we do now is simply stay on the i18n sync branch until we've detected that the branch has been merged into staging and only then do we switch back to staging. If all goes well, this should mean that the server is only ever moving "forwards" in git history. This is somewhat more fragile than the setup we had before, so it could very well break if things don't go well, but because the i18n server is fairly isolated I'd suggest we deal with that potential chaos as it arises, rather than trying to anticipate.
Links
Testing story
I tested this out manually and added a unit test for the new github functionality, but this will still need some close monitoring once it gets merged.
Reviewer Checklist: