Closed Bug 646833 Opened 10 years ago Closed 8 years ago

l10n verify should take l10n-changesets into account


(Release Engineering :: Release Automation: Other, defect, P4)



(Not tracked)



(Reporter: catlee, Unassigned)


(Whiteboard: [automation])


(2 files, 1 obsolete file)

l10n verify reports on ALL changes, regardless of if they're expected or not.

I think we should instead make it report success for a locale depending on if there were changes made to the locale according to the l10n changesets for the two releases being compared.
Attached patch First draft (obsolete) — Splinter Review
This is just a first draft, far from being complete. However, some input on the direction it is going would be most welcome.

So the idea is:
In the output of the diff command, I look for lines like (only locale files):
re.finditer('^diff -r <<(locale)_file_regex>>.*$', output, re.M) # | 'Only in ...' ??

If the locales found in the diff are exactly the same as the set of locales with different revisions in the old/new l10n_changesets, returns SUCCESS.
(if the diff contains diffs on other files than locales, it will always return SUCCESS, is this correct?)

Otherwise, returns FAILURE.

Should I be also looking for lines like  '^Only in ...' ??, right?
What is format of the locales files found in the diff <<(locale)_file_regex>> ?
Assignee: nobody → astoica
Attachment #532005 - Flags: review?(catlee)
Comment on attachment 532005 [details] [diff] [review]
First draft

This is a pretty good approach, but there are a few important details that need addressing:

- diffs_l10n_changesets needs to use asynchronous calls to fetch the data (look for other getPage() calls in buildbotcustom)

- diffs_l10n_changesets can't be called in __init__ and should instead run after the step has started. maybe call it in evaluateCommand? although, I'm not sure if you can return a deferred from there

Sample diff output can be found here:
Attachment #532005 - Flags: review?(catlee) → review+
It works like this, the L10nVerifyMetaDiff step was replaced by 2 new ones:
# diff -r new/diffs old/diffs > metadiff.out 
# python compare to changesets script metadiff.out l10nChUrl oldL10nChUrl
    # which, downloads new l10nchangesets from hg
    # downloads old l10nchangesets from hg
    # reads diffs file and makes checks

This way the steps (scripts) are run on the slave, and not the master.

A few questions:
1/ L10nVerifyFactory new init parameters: baseTag=None, oldBaseTag=None
If they are not provided, the 'verify_l10n_metadiff' step will fail. Should it ignore 
checking changesets files if not provided to ensure backwards compatibility and 
not be required to add in the 2 new parameters everywhere where L10nVerifyFactory is initialized?

Where should I fill in the config parameters? (baseTag, oldBaseTag)

2/ Changesets URL
changesetsRepoPath = 'build/buildbot-configs/file/%(tag)s/mozilla/l10n-changesets_mozilla-2.0'
Should the 2 last segments be customizable too? Which are the configs for them?

3/ Python step environment? When calling 'verify_l10n_metadiff' step, should I provide some 
kind of Python environment? I see some other steps use env=self.env.copy(), as args.

(see also patch for tools, containing the script)
Attachment #532005 - Attachment is obsolete: true
Attachment #533742 - Flags: review?(catlee)
Attached patch Progress Tools 1Splinter Review
Script which downloads current and old l10n changesets

Parses 'metaDiffOutput' meta diffs file looking for diffs in locales.
    It returns true, if all diffs in 'metaDiffOutput' correspond to locales 
    with different revision numbers in ch1 and ch2, or present only in one 
    of them. Otherwise, returns false.

I tested this script with several scenarios and works great. Also tested it on the 120MB diff file that I got from you.

Haven't figured out how to test the factory in the previous patch. How should I test it?
Attachment #533749 - Flags: review?(catlee)
Assignee: astoica → catlee
Attachment #533742 - Flags: review?(catlee)
Attachment #533749 - Flags: review?(catlee)
Assignee: catlee → nobody
No longer blocks: hg-automation
Mass move of bugs to Release Automation component.
Component: Release Engineering → Release Engineering: Automation (Release Automation)
No longer blocks: hg-automation
l10n verify is dead.
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: → Release Engineering
You need to log in before you can comment on or make changes to this bug.