Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiment with i18n caches in CI #6724

Draft
wants to merge 1 commit into
base: trunk
Choose a base branch
from
Draft

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Mar 13, 2024

Fixes #

To test:

PR submission checklist:

  • I have considered adding unit tests where possible.
  • I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

@mokagio mokagio marked this pull request as draft March 13, 2024 03:09
@mokagio mokagio force-pushed the mokagio/cache-npm-in-buildkite-2 branch from 7bd057c to 50a3471 Compare March 13, 2024 04:57
Base automatically changed from mokagio/cache-npm-in-buildkite-2 to trunk March 13, 2024 13:05
@geriux
Copy link
Contributor

geriux commented Mar 19, 2024

Hey @mokagio 👋 I was wondering how this experiment was going. It looks like the i18n cache is being loaded correctly as I saw in this job 🤩

@mokagio mokagio force-pushed the mokagio/i18n-cache branch from d7eacdc to 3ef013f Compare March 21, 2024 05:07
@mokagio
Copy link
Contributor Author

mokagio commented Mar 21, 2024

Hey @geriux . I started this but then stopped because I wanted to learn more about the cache. Maybe you can answer my question.

How does the codebase know about the i18n cache validity? I mean, the only check I've seen in the code is "is the cache in the repo? if not, download" but how is this cache maintained and updated?

For the purpose of the automation here, would looking at when package.json changes be a good proxy for when to update the cache? Or are there better files to check?

Thanks!

@geriux
Copy link
Contributor

geriux commented Mar 21, 2024

How does the codebase know about the i18n cache validity? I mean, the only check I've seen in the code is "is the cache in the repo? if not, download" but how is this cache maintained and updated?

This cache folder only stores the un-optimized translations, there's no mechanism currently to invalidate its content other than manually running npm run i18n:update.

When we run the Build JS Bundles Buildkite job for tag releases it runs npm run prebundle:js which calls npm run i18n:update to fetch the latest strings and it also optimizes them.

For the purpose of the automation here, would looking at when package.json changes be a good proxy for when to update the cache? Or are there better files to check?

I think we could rely on the version of the app? If we can pick the version of the package.json I think that would be great to use as part of the cache key to invalidate it. @fluiddot Do you think that's a good approach for this?

@fluiddot
Copy link
Contributor

How does the codebase know about the i18n cache validity? I mean, the only check I've seen in the code is "is the cache in the repo? if not, download" but how is this cache maintained and updated?

Updating the localizations is a bit tricky process because it requires analyzing the React Native bundle. The scripts behind the i18n:update command mainly seek for the used strings in the native editor. Hence, I don't think there's an optimal way to validate the cache without running that process.

Further information can be found in: p9ugOq-2xq-p2.

I think we could rely on the version of the app? If we can pick the version of the package.json I think that would be great to use as part of the cache key to invalidate it. @fluiddot Do you think that's a good approach for this?

Yep, as you pointed out @geriux, we only generate the optimized localizations in releases. Although to be accurate, we run this process when pushing a Git tag, so this would also cover when creating alpha versions. Using an outdated version of localizations in alpha builds shouldn't be an issue, as translations are expected to be included only in final releases. That said, I think relying on the version of the app would work as a way to validate the localizations cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants