484462 - m-c and m-1.9.1 builds no longer appear on L10n tinderbox waterfall pages

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Vlado Valastiak [:wladow]]

L10n browser builders are no longer reporting to L10n tinderbox waterfall pages like http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-sk

Last seen builds on waterfall pages: 2009/03/16
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-sk&maxdate=1237273322&hours=24&legend=0&norules=1

Nightlies are actually showing up on ftp server, so it's likely just reporting issue. Maybe related to re-versioning of 3.1 to 3.5?

Comment 1

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

At
 http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2/master.cfg#l108
the .values() looks like 
 [ ['Linux mozilla-central l10n', 'linux'], 
   ['WINNT 5.2 mozilla-central l10n', 'win32'], 
   ... 
 ]
since bug 482270. I suspect we have to pass only the first member of each list to TinderboxMailNotifier, so that there are matches when we do 
 http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2/master.cfg#l170
(adding the builder).

Comment 2

[Armen [:armenzg]]

Taking unless somebody wants it. I will attach a patch by tomorrow.

Comment 3

[Armen [:armenzg]]

Attachment: moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem and renaming the builders

I am taking advantage of this bug and I am also doing the renaming of bug 482451.

This patch needs staging testing but it worked locally. I didn't test in staging since coop was testing another bug overnight and he is not around.

BTW, are we going to rename [fx31x] or [fx32x] since Firefox has been renamed from 3.1 to 3.5?

Production patch available once this is reviewed positively

Comment 4

[Axel Hecht [:Pike]]

Comment on attachment 369009 [details] [diff] [review]
moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem and renaming the builders

r=me.

Regarding the renaming of fx31x etc, feel free to move those to fx35x and fx36x. I started to use those tree names in a second master locally.

Comment 5

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

Comment on attachment 369009 [details] [diff] [review]
moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem and renaming the builders

>diff -r 52c1f541ba03 mozilla2-staging/master-main.cfg
>@@ -156,14 +161,14 @@
>         nightly_scheduler=Nightly(
>             name=builder,
>             branch=branch['repo_path'],
>-            hour=[3], minute=[02],
>+            hour=[3],
>             builderNames=[builder]
>         )

Drive by comment - you shouldn't make this change, it's deliberately a couple of minutes after 3am so that the system clock on the master has a chance to settle after daylight savings changes.

Comment 6

[[e-mail] (:bhearsum)]

Comment on attachment 369009 [details] [diff] [review]
moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem and renaming the builders

In the future, please try and keep patches for different things separate. If we have to back out this patch because it further breaks the Schedulers, we'll lose the renames, too.

>diff -r 52c1f541ba03 mozilla2-staging/master-main.cfg
>--- a/mozilla2-staging/master-main.cfg	Fri Mar 20 15:29:58 2009 -0400
>+++ b/mozilla2-staging/master-main.cfg	Mon Mar 23 21:33:52 2009 -0400
>@@ -60,21 +60,26 @@
>     # generate a list of builders, nightly builders (names must be different)
>     # for easy access
>     for platform in branch['platforms'].keys():
>-        builders.append('%s build' % branch['platforms'][platform]['base_name'])
>+        base_name =  branch['platforms'][platform]['base_name']
>+        builders.append('%s build' % base_name)
>         # Skip l10n, unit tests and nightlies for debug builds
>         if platform.find('debug') >= 0:
>             continue
> 
>-        builder = '%s nightly' % branch['platforms'][platform]['base_name']
>+        builder = '%s nightly' % base_name
>         nightlyBuilders.append(builder)
>         if branch['enable_shark'] and platform in ('macosx'):
>-            nightlyBuilders.append('%s shark' % branch['platforms'][platform]['base_name'])
>+            nightlyBuilders.append('%s shark' % base_name) 
>         if branch['enable_l10n'] and platform in ('linux','win32','macosx'):
>-            l10nNightlyBuilders[builder] = \
>-              ['%s l10n' % branch['platforms'][platform]['base_name'],
>-               platform]
>+            l10nNightlyBuilders[builder] = {}
>+            l10nNightlyBuilders[builder]['builder'] = \

Using ...[builder]['builder'] is really confusing. How does l10nNightlyBuilders[builder]['l10n_builder'] sound, instead?

>+                '%s %s %s l10n' % (
>+                branch['product_name'].capitalize(),
>+                name,
>+                platform)
>+            l10nNightlyBuilders[builder]['platform'] = platform
>         if branch['enable_unittests'] and platform in ('linux','win32','macosx'):
>-            unittestBuilders.append('%s unit test' % branch['platforms'][platform]['base_name'])
>+            unittestBuilders.append('%s unit test' % base_name) 
> 
>     # Currently, each branch goes to a different tree
>     # If this changes in the future this may have to be
>@@ -107,7 +112,7 @@
>             extraRecipients=["[e-mail]"],
>             relayhost="mail.build.mozilla.org",
>             logCompression="bzip2",
>-            builders=l10nNightlyBuilders.values(),
>+            builders=l10nNightlyBuilders[builder].values(),

I don't think this works...l10nNightlyBuilders[builder].values() contains the builder name, but it also contains the platform, so you end passing, eg builders=['Firefox 1.9.1 linux l10n', 'linux']. Also note that 'builder' is just a leftover from the previous loop - you're only getting one builder here. If I do a 'print l10nNightlyBuilders[builder].values()' just above this block here's what I get:
['linux', 'Firefox mozilla-1.9.1 linux l10n']
['linux', 'Firefox mozilla-central linux l10n']

It's probably best to build the list around line 103, with something like...:
builders = []
for b in l10nNightlyBuilders:
    builders = l10nNightlyBuilders[b]['l10n_builder']

Does all of the above make sense to you?


>@@ -156,14 +161,14 @@
>         nightly_scheduler=Nightly(
>             name=builder,
>             branch=branch['repo_path'],
>-            hour=[3], minute=[02],
>+            hour=[3],

See Nick's comment about why you shouldn't change this.



I like the factoring you did with the base_name stuff near the top, good job on that.

r- because this patch actually won't work because of the problems with the TinderboxMailNotifier section

Comment 7

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

Comment on attachment 369009 [details] [diff] [review]
moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem and renaming the builders

(In reply to comment #6)
> In the future, please try and keep patches for different things separate. If we
> have to back out this patch because it further breaks the Schedulers, we'll
> lose the renames, too.

Yeah, let's get separate patches posted for the different issues. Remember that you can always do multiple commit locally and then push them all in one batch.

Comment 8

[Armen [:armenzg]]

Attachment: moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem

Attached the patch but I have to find out why I only have the column "Linux mozilla-1.9.1 l10n %" showing in http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaStaging

I am forwarding all email from the TinderboxMailNotifier to my own email. How can I find out why the emails for the other builders have not been sent?

Comment 9

[Armen [:armenzg]]

Comment on attachment 369101 [details] [diff] [review]
moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem

From IRC conversation, the MozillaStaging tree might be horked (see bug 467922).
I have reconfigured locally to send emails to MozillaTest instead of MozillaStaging.

Requesting reviews this time.

Comment 10

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

Comment on attachment 369101 [details] [diff] [review]
moz2-staging/{master-main.cfg,l10nbuilds.ini} - Fixing the tinderbox problem

Better.

Is there meant to be an associated patch to l10nbuilds.ini, or is that not required now?

Comment 11

[Armen [:armenzg]]

(In reply to comment #10)
> (From update of attachment 369101 [details] [diff] [review])
> Better.
> 
> Is there meant to be an associated patch to l10nbuilds.ini, or is that not
> required now?
>
No need since I am not renaming the builders. Once we get the other approval this is ready to check-in.

I will write the patch for production during the next 24 hours.

Comment 12

[Armen [:armenzg]]

Attachment: staging & production - fixes that l10n builds do not show on tinderbox

This adds the changes for production and it fixes something that I did not notice before. I now use .append instead of = for appending the l10n builders. This is why I was able to see only 2 builders yesterday (one per branch) and not all 6 builders.

This is working in staging and reporting to MozillaTest. It is ready for review and commit after that.

     if branch['enable_l10n']:
+        l10n_builders = []
+        for b in l10nNightlyBuilders:
+            l10n_builders.append(l10nNightlyBuilders[b]['l10n_builder'])
         # This notifies all l10n related build objects to Mozilla-l10n
         c['status'].append(TinderboxMailNotifier(

Comment 13

[[e-mail] (:bhearsum)]

Comment on attachment 369521 [details] [diff] [review]
staging & production - fixes that l10n builds do not show on tinderbox 

Looks good to me

Comment 14

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

Comment on attachment 369521 [details] [diff] [review]
staging & production - fixes that l10n builds do not show on tinderbox 

changeset:   1044:4666c9ed0f38