474898 - l10n builds not pulling en-US tip properly

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Nick Thomas [:nthomas] (UTC+12)]

For l10n builds, we're doing this
  if [ -d mozilla-central ]; then 
     hg -R mozilla-central pull -r tip ; 
  else 
     hg clone http://hg.mozilla.org/mozilla-central ; 
  fi
for our copy of mozilla-central, and also for the locale. Which is busted in the case where you already have a clone, because the pull grabs the changes but never applies them to the working copy, so we're not building what we should be. Noticed this when bug 472431 wasn't having the right affect.

Why do we have the '-r tip' there ? So that we can use the en-US nightly  revision at some point in the future ? I think we want 'hg pull; hg up -r rev' in that case. Can we just start using the Mercurial stuff in buildbot ?

Comment 1

[Armen [:armenzg]]

True, we are missing the update step
(Link to mentioned code http://mxr.mozilla.org/mozilla/source/tools/buildbotcustom/process/factory.py#737)

The l10n stuff, checked out is "updated" in:
http://mxr.mozilla.org/mozilla/source/tools/buildbotcustom/process/factory.py#763
but we as mentioned we forgot to add the "update" step for en-US, we should add it here:
http://mxr.mozilla.org/mozilla/source/tools/buildbotcustom/process/factory.py#834

Changing "tip" for "default" should be good too.

Nick, here is the bug were we removed the Mercurial step for the "if" structure
https://bugzilla.mozilla.org/show_bug.cgi?id=472568

Comment 2

[Axel Hecht [:Pike]]

Sadly, for l10n builds the Mercurial stuff get's confused about revisions between the various repos, and ends up clobbering etc.

This command is really missing a

; hg update -R mozilla-central -r default

where default could be a build property.

Compare 
http://mxr.mozilla.org/mozilla/source/tools/buildbotcustom/process/factory.py#737
and 
http://hg.mozilla.org/users/axel_mozilla.com/tooling/file/591f1b71d39c/buildbotcustom/buildbotcustom/process/factory.py#l9

Comment 3

[Chris Cooper [:coop] (he/him)]

Attachment: Add an "hg update" for main checkout and l10n

Axel: I think your suggestion about using a build property is a good one, but we don't really have an entry point for setting it dynamically AFAICT. Suggestions welcome.

For now, I just set both revisions to 'default' in the existing callback.

Also fixed up some places where we specify 'tip' instead of 'default.'

Comment 4

[Axel Hecht [:Pike]]

Comment on attachment 359312 [details] [diff] [review]
Add an "hg update" for main checkout and l10n

We should either hard-code default or use baseTag, mixing the two isn't good, I think.

I'd prefer the source of the properties to be just "Scheduler". For one because I don't think that additional level of detail helps a lot, and for the very selfish reason that I love databases for the string size requirements. I picked 20, given that Scheduler seemed to be the longest by far for my mbdb db.

I'd prefer "en_revision" over "revision", there isn't a single revision for l10n builds, so being specific helps, IMHO. Style nit, mixing "strings" and 'strings'.

Comment 5

[Chris Cooper [:coop] (he/him)]

Attachment: Add an "hg update" for main checkout and l10n, v2

Addressed Axel's comments.

Comment 6

[Chris Cooper [:coop] (he/him)]

Comment on attachment 359325 [details] [diff] [review]
Add an "hg update" for main checkout and l10n, v2

changeset:   178:7ca9fa5a6595

Comment 7

[Chris Cooper [:coop] (he/him)]

Now running in production.