SeaMonkey:Release Process:2.0b2: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 25: Line 25:
*Forgot to "hg pull -u" buildbots-configs and reconfigure the master, so did that and kicked off the process once more.
*Forgot to "hg pull -u" buildbots-configs and reconfigure the master, so did that and kicked off the process once more.
* Probably because the builds for the first tagging were still in the queue when I kicked it off the second time, the tagging failed to trigger its followup steps. I initiated the source and build steps from the web interface. The mac slave got lost while building, needed to trigger it another time.
* Probably because the builds for the first tagging were still in the queue when I kicked it off the second time, the tagging failed to trigger its followup steps. I initiated the source and build steps from the web interface. The mac slave got lost while building, needed to trigger it another time.
* As I had triggered things manually, they weren't kicking off any followup steps automatically, so I stubbed out tag/source/*_build with a dummy and triggered the process again once all builds had been done. This correctly triggered all the L10n repacks.


== Wall Clock Time ==
== Wall Clock Time ==

Revision as of 23:54, 4 September 2009

Build Harness

SeaMonkey:Release Automation

Bugs

Tracking bug filed as bug 512085

Build Engineer

Robert Kaiser

Signed-off Revisions

http://hg.mozilla.org/comm-central/rev/34ba282bf549
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ac59325cf0a9
http://hg.mozilla.org/dom-inspector/rev/ca35d7b7c443
http://hg.mozilla.org/venkman/rev/10ee9dce95c6
chatzilla CVS timestamp: 2009-09-03 00:00

L10n revisions according to opt-ins as listed in l10n-changesets

Notes

Build

  • Updated shipped-locales, l10n-changesets, release-config.py
  • Kicked off with the following command:
buildbot sendchange --username=kairo --master=localhost:9010 --branch=comm-central -m "SeaMonkey 2.0b2build1" doit
  • Forgot to "hg pull -u" buildbots-configs and reconfigure the master, so did that and kicked off the process once more.
  • Probably because the builds for the first tagging were still in the queue when I kicked it off the second time, the tagging failed to trigger its followup steps. I initiated the source and build steps from the web interface. The mac slave got lost while building, needed to trigger it another time.
  • As I had triggered things manually, they weren't kicking off any followup steps automatically, so I stubbed out tag/source/*_build with a dummy and triggered the process again once all builds had been done. This correctly triggered all the L10n repacks.

Wall Clock Time

Build

  • buildbot sendchange: Thu Sep 3 08:06:59 PDT 2009
  • tag:
    • Start: Thu Sep 3 09:10:39 2009
    • End: Thu Sep 3 09:27:35 2009 (automatic triggering of other steps failed due to the initial mess-up with tagging and still having builds in the queue when triggering the correct tagging)
    • Elapsed: 16 mins, 56 secs
  • source:
    • Start: Thu Sep 3 11:00:40 2009
    • End: Thu Sep 3 11:10:11 2009
    • Elapsed: 9 mins, 31 secs
  • linux_build:
    • Start: Thu Sep 3 11:01:55 2009
    • End: Thu Sep 3 12:18:43 2009
    • Elapsed: 1 hrs, 16 mins, 47 secs
  • win32_build:
    • Start: Thu Sep 3 10:35:08 2009
    • End: Thu Sep 3 12:48:59 2009
    • Elapsed: 2 hrs, 13 mins, 50 secs
  • macosx_build:
    • (failed) Start: Thu Sep 3 10:22:48 2009 - slave lost after 29min
    • Start: Thu Sep 3 16:51:00 2009
    • End: Thu Sep 3 21:25:06 2009
    • Elapsed: 4 hrs, 34 mins, 5 secs
  • linux_repack
    • Start: Fri Sep 4 12:14:42 2009
    • End: Fri Sep 4 12:52:56 2009
  • win32_repack
    • Start: Fri Sep 4 12:31:41 2009
    • End: Fri Sep 4 15:14:23 2009
  • macosx_repack
    • Start: Fri Sep 4 14:23:39 2009
    • End: Fri Sep 4 16:27:56 2009
  • updates