Currently, it just iterates over the lot, it'd be nice (for l10nupdate usages) if we could pass a parameter to scap-rebuild-cdbs of the mediawiki version to rebuild
Version: unspecified
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | bd808 | T72752 [l10n] l10nupdate process should respect the scap lock file | |||
| Resolved | bd808 | T72443 [l10n] Use Scap in Localisation Update | |||
| Resolved | None | T72446 [l10n] [scap] Are Scap and LocalisationUpdate actually fighting over l10nupdates? |
As a no-op for a version, it's still a tonne quicker than the current method (see https://gerrit.wikimedia.org/r/#/c/158623 for improvements), so running the extra iterations isn't the biggest issue.
On second thought, is this worth doing? Should I just rework the script so that it does the 3 rebuilds, syncs, and then does just one call to rebuild the cdbs?
That block could nearly just be replaced with a scap call, couldn't it?
The only real difference is the LocalisationUpdate call out (at a quick glance, scap doesn't do anything with LU currently) https://github.com/wikimedia/operations-puppet/blob/production/files/misc/l10nupdate/l10nupdate-1#L87-L89
The updating of the source repos needs to be done first (so that can stay for now), and then the refresh of the RL cache needs doing after...
gerritadmin wrote:
Change 158623 had a related patch set uploaded by Greg Grossmeier:
Use sync-dir to copy out l10n json files, build cdbs on hosts
gerritadmin wrote:
Change 158623 merged by Springle:
Use sync-dir to copy out l10n json files, build cdbs on hosts