compare staging-1.9 and production-1.9 for discrepancies

RESOLVED FIXED

Status

Release Engineering
General
P1
normal
RESOLVED FIXED
10 years ago
5 years ago

People

(Reporter: armenzg, Assigned: armenzg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 7 obsolete attachments)

(Assignee)

Description

10 years ago
Created attachment 340670 [details]
differences between production 1.9 and staging 1.9
(Assignee)

Comment 1

10 years ago
Comparing these two files will allow us to know what are discrepancies and if we will have any more surprises on activating the l10n repackages in parallel in production 1.9
(Assignee)

Comment 2

10 years ago
Created attachment 340808 [details] [diff] [review]
adding max_builds=1 to all slaves, making staging-1.9 to report to MozillaStaging instead of MozillaTest
Attachment #340808 - Flags: review?(ccooper)
(Assignee)

Comment 3

10 years ago
Comment on attachment 340808 [details] [diff] [review]
adding max_builds=1 to all slaves, making staging-1.9 to report to MozillaStaging instead of MozillaTest

>-c['schedulers'].append(shark_scheduler)
>-c['schedulers'].append(depend_scheduler)
>+#c['schedulers'].append(shark_scheduler)
>+#c['schedulers'].append(depend_scheduler)
>
These schedulers are always commented out in staging-1.9, that is why I think it should be permanent. We always have to remember to comment it out every time we want to do a run of anything else
(Assignee)

Comment 4

10 years ago
Comment on attachment 340670 [details]
differences between production 1.9 and staging 1.9

>--- production-1.9/master.cfg	Wed Sep 24 16:00:46 2008
>+++ staging-1.9/master.cfg	Wed Sep 24 10:15:32 2008
>@@ -1,7 +1,7 @@
> # -*- python -*-
> # ex: set syntax=python:
> 
>-# This is the production buildmaster config file for Mozilla Firefox 1.9 (aka Firefox 3.0.0.x). 
>+# This is the staging buildmaster config file for Mozilla Firefox 1.9 (aka Firefox 3.0.0.x). 
> 
> # Use shorter alias to save typing.
> c = BuildmasterConfig = {}
>@@ -20,11 +20,15 @@
> from buildbot.buildslave import BuildSlave
> 
> c['slaves'] = [
>- BuildSlave("production-1.9-master",""),
>- BuildSlave("fx-linux-1.9-slave2",""),
>- BuildSlave("fx-win32-1.9-slave2", ""),
>- BuildSlave("fx-linux64-1.9-slave1", ""),
>- BuildSlave("fx-mac-1.9-slave2", ""),
>+ BuildSlave("staging-1.9-master",""),
>+ BuildSlave("fx-linux-1.9-slave1",""),
>+ BuildSlave("fx-linux-1.9-slave3",""),
>+ BuildSlave("fx-linux-1.9-slave4",""),
>+ BuildSlave("fx-win32-1.9-slave1", ""),
>+ BuildSlave("fx-win32-1.9-slave3", ""),
>+ BuildSlave("fx-win32-1.9-slave4", ""),
>+ BuildSlave("mini-test", ""),
>+ BuildSlave("fx-mac-1.9-slave1", ""),
> ]
> 
> # 'slavePortnum' defines the TCP port to listen on. This must match the value
>@@ -34,7 +38,7 @@
> 
> ####### CHANGESOURCES
> 
>-# the 'change_source' list tells the buildmaster how it should find out about
>+# the 'sources' list tells the buildmaster how it should find out about
> # source code changes. Any class which implements IChangeSource can be added
> # to this list: there are several in buildbot/changes/*.py to choose from.
> 
>@@ -57,15 +61,14 @@
> 
> from buildbot.scheduler import Scheduler, Nightly, Dependent, Periodic
> from buildbot.changes.pb import PBChangeSource
>-from buildbotcustom.l10n.scheduler import NightlyL10n
>+from buildbotcustom.l10n.scheduler import NightlyL10n, DependentL10n
> from buildbotcustom.l10n.l10n import BuildL10n
> 
>-
> c['schedulers'] = []
> 
>-# For buildbot-driven nightly builders
>-nightly_scheduler = Nightly(
>- name='nightly_scheduler',
>+# For nightly shark only
>+shark_scheduler = Nightly(
>+ name='nightly_shark',
>  branch='HEAD',
>  hour=[01],
>  builderNames=[
>@@ -73,11 +76,21 @@
>  ]
> )
> 
>+# For nightly depend only
>+depend_scheduler = Periodic(
>+ name='depend', 
>+ periodicBuildTimer=(60 * 5),
>+ branch='HEAD',
>+ builderNames=[
>+  'linux_dep_build',
>+  'win32_dep_build',
>+  'macosx_dep_build',
>+ ]
>+)
>+
> l10n_nightly_scheduler = NightlyL10n(
>  name='nightly',
>-#have l10n repackages every 4 hours and
>-#leave a gap for the en-US builds that happen at 5AM 
>- hour=[1,9,13,17,21],
>+ hour=[0,9,12,15,18,21],
>  builderNames=[
>   'linux_l10n_nightly',
>   'win32_l10n_nightly',
>@@ -85,33 +98,37 @@
>  ],
>  cvsRoot=':ext:stgbld@cvs.mozilla.org:/cvsroot',
> # You can specify your own list of locales
>-# locales=['en-GB','af','de']
>+# locales=['af','en-GB','de']
> )
> BuildL10n.buildQueue = l10n_nightly_scheduler 
> 
>-# For depend only builders
>-depend_scheduler = Periodic(
>- name='depend', 
>- periodicBuildTimer=(60 * 5),
>- branch='HEAD',
>- builderNames=[
>-  'linux_dep_build',
>-  'win32_dep_build',
>-  'macosx_dep_build',
>- ]
>-)
>-
>-tag_scheduler = Scheduler (
>- name="tag_scheduler",
>- treeStableTimer=0,
>- builderNames=["tag"],
>+# For release only
>+slave_prestage_scheduler = Scheduler(
>+ name="slave_prestage",
>  branch=None,
>+ treeStableTimer=0,
>+ builderNames=["linux_prestage", "win32_prestage", "macosx_prestage"],
> )
> 
> ####### DEPENDENT SCHEDULERS
>+prestage_depscheduler = Dependent(
>+ name="prestage",
>+ upstream=slave_prestage_scheduler,
>+ builderNames=["prestage"],
>+)
>+cvsmirror_depscheduler = Dependent(
>+ name="cvsmirror_dep",
>+ upstream=prestage_depscheduler,
>+ builderNames=["cvsmirror"],
>+)
>+tag_depscheduler = Dependent(
>+ name="tag_dep",
>+ upstream=cvsmirror_depscheduler,
>+ builderNames=["tag"],
>+)
> build_depscheduler = Dependent(
>  name="build_dep",
>- upstream=tag_scheduler,
>+ upstream=tag_depscheduler,
>  builderNames=["source", "linux_build", "macosx_build", "win32_build"],
> )
> sign_depscheduler = Dependent(
>@@ -131,11 +148,14 @@
>                "macosx_update_verify", "stage"],
> )
> 
>-#c['schedulers'].append(nightly_scheduler)
>-#c['schedulers'].append(depend_scheduler)
>+c['schedulers'].append(shark_scheduler)
>+c['schedulers'].append(depend_scheduler)
> c['schedulers'].append(l10n_nightly_scheduler)
> 
In staging we have the shark scheduler

>-c['schedulers'].append(tag_scheduler)
>+c['schedulers'].append(slave_prestage_scheduler)
>+c['schedulers'].append(prestage_depscheduler)
>+c['schedulers'].append(cvsmirror_depscheduler)
>+c['schedulers'].append(tag_depscheduler)
>
In staging we have these extra 4 dependent schedulers and we don't have the tag_scheduler

> from buildbot.process import factory
> from buildbotcustom.process.factory import BootstrapFactory
> from buildbot.steps.shell import ShellCommand, Configure, Compile, WithProperties
> from buildbot.steps.transfer import FileDownload
>-import buildbotcustom.steps.misc
>-import buildbotcustom.steps.transfer
>-reload(buildbotcustom.steps.misc)
>-reload(buildbotcustom.steps.transfer)
>-from buildbotcustom.steps.misc import GetBuildID
>-from buildbotcustom.steps.transfer import MozillaStageUpload
>-
In staging we seem to not use GetBuildID, MozillaStageUpload

>+#Since we are wgetting from ftp.m.o but using code from staging
>+L10nNightlyFactory.addStep(ShellCommand(
>+    command=["cvs", "-q", "-z3", "-d", cvsroot, "co",
>+             "mozilla/browser/config/version.txt"],
>+    descriptionDone="version.txt",
>+    workdir=".",
>+    haltOnFailure = True
>+    ))
>
We are wgetting from ftp.m.o since we don't have en-US nightly builds in the staging ftp
Should I make staging to pull ALL the code and the en-US binary from ftp.m.o and remove this step?
It should not affect any of the results

>@@ -423,9 +442,9 @@
> c['builders'].append(
>  {
>   'name': 'macosx_l10n_nightly',
>-  'slavename': 'fx-mac-1.9-slave2',
>+  'slavename': 'fx-mac-1.9-slave1',
>   'builddir': 'macosx_l10n_nightly',
>-  'locks': [linux_lock],
>+  'locks': [macosx_lock],
I should fix this

>-  'locks': [linux_lock],
>+  'locks': [win32_lock],
and this
(Assignee)

Comment 5

10 years ago
Created attachment 340814 [details] [diff] [review]
production-1.9/master.cfg & staging-1.9/master.cfg

1) adding max_builds=1 to all slaves 
2) making staging-1.9 to report to MozillaStaging instead of MozillaTest
3) fixed mac and windows locks
Assignee: nobody → armenzg
Attachment #340808 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #340814 - Flags: review?(ccooper)
Attachment #340808 - Flags: review?(ccooper)

Comment 6

10 years ago
Comment on attachment 340814 [details] [diff] [review]
production-1.9/master.cfg & staging-1.9/master.cfg

For parts that are changing in the staging env vs. production, can we add comments with a clear explanation of why the change is necessary? That way we don't have to rely on remembering to update those vars, we can just grep for a common comment string and make the necessary changes.

e.g. 
# STAGING: there are no shark or depend schedulers in staging
#c['schedulers'].append(shark_scheduler)
#c['schedulers'].append(depend_scheduler)
Attachment #340814 - Flags: review?(ccooper) → review-
(Assignee)

Comment 7

10 years ago
Created attachment 340944 [details] [diff] [review]
 production-1.9/master.cfg & staging-1.9/master.cfg
Attachment #340814 - Attachment is obsolete: true
Attachment #340944 - Flags: review?(ccooper)
(Assignee)

Updated

10 years ago
Attachment #340944 - Flags: review?(ccooper)

Comment 8

10 years ago
Comment on attachment 340944 [details] [diff] [review]
 production-1.9/master.cfg & staging-1.9/master.cfg   

r+ if you can add the same staging comments to the production config.

Having the #STAGING comments in only one or the other will just add noise to the delta, which is what we're trying to minimize.
Attachment #340944 - Flags: review+
Did you also get to confirm that the staging master has *no* local patches and is cleanly only running what is checked into cvs?
Priority: -- → P1
(Assignee)

Comment 10

10 years ago
(In reply to comment #9)
> Did you also get to confirm that the staging master has *no* local patches and
> is cleanly only running what is checked into cvs?

confirmed in staging-1.9:
- master.cfg
- buildbotcustom
- cvsmirror

confirmed in staging-1.9:
- master.cfg
- buildbotcustom
(Assignee)

Comment 11

10 years ago
Created attachment 340954 [details]
 differences between production 1.9 and staging 1.9

I have reduced the differences to the minimum but this will mean a larger patch
Attachment #340670 - Attachment is obsolete: true
(Assignee)

Comment 12

10 years ago
Created attachment 340955 [details] [diff] [review]
fixes the maximum of discrepancies that I could find between production-1.9 and staging-1.9
Attachment #340944 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #340955 - Flags: review?(ccooper)

Comment 13

10 years ago
Comment on attachment 340955 [details] [diff] [review]
fixes the maximum of discrepancies that I could find between production-1.9 and staging-1.9

+# STAGING: only in staging
+# For release only
 tag_scheduler = Scheduler (

This comment doesn't make any sense. Please fix.

Maybe the best thing you can do if to run a diff between the production master.cfg and the staging master.cfg. Ideally, the only deltas I want to see are:

* variable changes relevant to production vs. staging
* code sections that are commented out. Please note that #STAGING comments that proceed these sections should appear in *both* master.cfg files. Feel free to add a #PRODUCTION comment section if required (again to both configs).

Please provide the output of that diff between production and staging, and also attach the updated diff against CVS.
Attachment #340955 - Flags: review?(ccooper) → review-
(Assignee)

Comment 14

10 years ago
Created attachment 340991 [details] [diff] [review]
l10n fixes for production-1.9 and staging-1.9

Let's separate cleaning up stuff from what have to be fixes so the l10n stuff is the same in production and staging

Relevant fixes in this patch:
1) added maxBuilds=1
2) removed cvsStagingRoot since it is not used
3) removed step to get version.txt from cvsroot (removing this is already tested in staging-1.9)
4) staging reports to MozillaStaging
5) no usage of uploadPathExperimental
6) uploading to nightly/latest-mozilla1.9.0-l10n
7) fixed LOCKS
8) fixed binaryURL to point to nightly/latest-mozilla1.9.0-l10n instead of nightly/experimental/latest-mozilla1.9.0-l10n
Attachment #340955 - Attachment is obsolete: true
Attachment #340991 - Flags: review?(ccooper)
(Assignee)

Comment 15

10 years ago
Created attachment 340995 [details]
differences between the two master.cfg files

I have removed any differences that does not have to do with l10n
Attachment #340954 - Attachment is obsolete: true
(Assignee)

Comment 16

10 years ago
Created attachment 340996 [details] [diff] [review]
[checked in] l10n fixes for production-1.9 and staging-1.9

Missed a line in production-1.9:
instead of MozillaTest it has to be Mozilla-l10n
line 177 of the patch
Attachment #340991 - Attachment is obsolete: true
Attachment #340996 - Flags: review?(ccooper)
Attachment #340991 - Flags: review?(ccooper)

Updated

10 years ago
Attachment #340995 - Attachment mime type: application/octet-stream → text/plain

Updated

10 years ago
Attachment #340996 - Flags: review?(ccooper) → review+

Comment 17

10 years ago
Comment on attachment 340995 [details]
differences between the two master.cfg files

Is this diff with your new changes, or before they are applied? Either way, looks promising. Not too much to fix up.
(Assignee)

Comment 18

10 years ago
(In reply to comment #17)
> (From update of attachment 340995 [details])
> Is this diff with your new changes, or before they are applied? Either way,
> looks promising. Not too much to fix up.

After changes

Updated

10 years ago
Attachment #340996 - Attachment description: l10n fixes for production-1.9 and staging-1.9 → [checked in] l10n fixes for production-1.9 and staging-1.9
(Assignee)

Comment 19

10 years ago
Let's open a new bug if we are going to make the configuration files from production-1.9 and staging-1.9 to be as similar as possible to ease doing diffs between the two of them

Regarding l10n repackages, this bug is fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.