685133 - Create a Lightning Beta release for TB 7.0 using as much automation as possible

Status: VERIFIED FIXED

(Calendar :: Build Config, defect)

Description

[Mark Banner (:standard8)]

Ok, the idea here is we'll use automation as much as possible, but with the basic aim being to get a release that works alongside TB 7.0 out.

Comment 1

[Mark Banner (:standard8)]

This should also help to weed out the holes we've got, plus provide a better understanding of what really needs to be fixed.

Comment 2

[Mark Banner (:standard8)]

First things first, I've updated the official buildbot-configs repo with the latest version from the calendar buildbot master:

http://hg.mozilla.org/build/buildbot-configs/rev/e08b1155ba1a

Comment 3

[Mark Banner (:standard8)]

Some more steps:

- Add build config with comm-beta configuration and update the release config so that it'll work with comm-beta
-- http://hg.mozilla.org/build/buildbot-configs/rev/4b121a84c4a2
- Remove old mozconfigs:
-- http://hg.mozilla.org/build/buildbot-configs/rev/a9e914f7e763
- Add new mozconfigs for comm-beta:
-- http://hg.mozilla.org/build/buildbot-configs/rev/c3f9b6cea69a
- Tweaks to enable clobberer for the release builders, and to actually use the tag_factory rather than replace it with a dummy:
-- http://hg.mozilla.org/build/buildbot-configs/rev/cea01027adb3

At this stage, we're at the place where we can tag builds, and I suspect source tarball generation will also work.

The unfortunate bit is that because we've not used automation for 6 months or so, the calbld account has expired. I've filed bug 685145 to get that up and running again, and will push for it in the next 24 hours.

Comment 4

[Worcester12345]

Bug 401779 - Integrate Lightning Into Thunderbird by Default and Ship Thunderbird with Lightning Enabled would take care of this on a more permanent basis.

Comment 6

[Mark Banner (:standard8)]

I've now tweaked the release options so that we now show the builders ready for actually building lighting:

http://hg.mozilla.org/build/buildbot-configs/rev/95d201907e10

Note that I had to do a few tweaks in the local buildbotcustom to get these to work as it didn't know about some of the newer platforms.

Comment 7

[Stefan Sitter [:ssitter]]

Linux comm-beta lightning build fails with the same 'GLIBCXX_3.4.14 not found' elfhack error as in Bug 678013.

Currently both comm-beta and comm-aurora builds report to <http://tinderbox.mozilla.org/showbuilds.cgi?tree=Calendar1.0>. Maybe they could report to Calendar-Beta and Calendar-Aurora instead?

Comment 8

[Mark Banner (:standard8)]

(In reply to Stefan Sitter from comment #7)
> Linux comm-beta lightning build fails with the same 'GLIBCXX_3.4.14 not
> found' elfhack error as in Bug 678013.

Filed bug 685818. I can't see anything in the configs, so I'm putting this down to a builder issue.

> Currently both comm-beta and comm-aurora builds report to
> <http://tinderbox.mozilla.org/showbuilds.cgi?tree=Calendar1.0>. Maybe they
> could report to Calendar-Beta and Calendar-Aurora instead?

If Philippe's happy with this then I'm happy for it as well. I'd just dumped them there for now as it was an existing place.

Comment 9

[Mark Banner (:standard8)]

I've got tagging to work (finally!). I've just landed mozconfigs for the release configuration (not that there's much different):

http://hg.mozilla.org/build/buildbot-configs/rev/f58d64640d96

I'm now working on getting at least the initial runs of the builders to work.

Comment 10

[Mark Banner (:standard8)]

Source tarball is here:

http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/1.0b6-candidates/

The rest of the builds will go there for now, but I'll move them across later, and fix the buildbot upload location later.

Comment 11

[Stefan Sitter [:ssitter]]

Next release ought to be 1.0b7. But the checkin http://hg.mozilla.org/releases/comm-beta/rev/a84cf3f04d33 lowered the version number from 1.0b7pre to 1.0b6?

Comment 12

[Mark Banner (:standard8)]

(In reply to Stefan Sitter from comment #11)
> Next release ought to be 1.0b7. But the checkin
> http://hg.mozilla.org/releases/comm-beta/rev/a84cf3f04d33 lowered the
> version number from 1.0b7pre to 1.0b6?

Well it was originally going to be 1.0b6 ;-)  However I was aware about the version change to 1.0b7 but as we've not finalised what we're releasing for this release but we're still getting automation working, I thought it wouldn't hurt to get this built as 1.0b6 even if we have to rebuild for 1.0b7 - the process will hopefully be a lot simpler this time around.

I'm also aware that the builds have uploaded the wrong stuff to ftp (thunderbird not lightning), I'm looking at fixing that now.

Comment 13

[Mark Banner (:standard8)]

Attachment: Create upload target for calendar

This patch creates a make upload target that I've been using on the relbranch. It allows us to get the right xpi from the right place and upload it into the appropriate place on ftp.

I've now got a build 4 running with this, this should give us windows & mac en-US builds plus separate packages for linux (bug 656350).

I'll be merging the linux builds by hand for now (I assume AMO can't handle different linux architectures).

This will give us en-US builds for the current beta at least.

Once these are produced, I'll move them into a more obvious place in ftp and we can advertise them.

We can then fix up the l10n stuff that needs doing.

Comment 14

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 560225 [details] [diff] [review]
Create upload target for calendar

Review of attachment 560225 [details] [diff] [review]:
-----------------------------------------------------------------

Does using this also get rid of the <platform>-xpi links in http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/ ?

r=philipp

::: calendar/lightning/lightning-packager.mk
@@ +152,5 @@
> +	$(INSTALL) $(IFLAGS1) $(DIST)/universal/xpi-stage/lightning.xpi $(DIST)/$(MOZ_PKG_PLATFORM)
> +	$(INSTALL) $(IFLAGS1) $(DIST)/universal/xpi-stage/gdata-provider.xpi $(DIST)/$(MOZ_PKG_PLATFORM)
> +else
> +	$(INSTALL) $(IFLAGS1) $(DIST)/xpi-stage/lightning.xpi $(DIST)/$(MOZ_PKG_PLATFORM)
> +	$(INSTALL) $(IFLAGS1) $(DIST)/xpi-stage/gdata-provider.xpi $(DIST)/$(MOZ_PKG_PLATFORM)

I'm fine with this now since we want to get things rolling, but maybe its better to put the source filenames into UPLOAD_FILES and then use something like:

for i in $(UPLOAD_FILES); do $(NSINSTALL) $(IFLAGS1) $$i $(DIST)/$(MOZ_PKG_PLATFORM)/; done

and for the upload.py step use

$(addprefix $(DIST)/$(MOZ_PKG_PLATFORM)/,$(basename $(UPLOAD_FILES)))

or similar.

Comment 15

[Mark Banner (:standard8)]

The last round of release changes produced en-US only Lightning builds:

http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/1.0b6-candidates/build4/

The only additional item I had to do above automation was to merge the linux 32 & 64 builds together.

Comment 16

[Mark Banner (:standard8)]

Attachment: [checked in] Update shipped-locales file

I've just been working on getting the l10n repack working, I noticed that shipped-locales was out of date.

This syncs it with http://hg.mozilla.org/build/buildbot-configs/file/a66944ad1817/calendar/l10n-calendar-changesets which was the 1.0b5 release, if you want more locales, we'll need to update it again.

Comment 17

[Mark Banner (:standard8)]

Attachment: Create upload target for calendar v2

Very minor tweak - upload from lightning-all.xpi rather than lightning.xpi. I'll then be fixing buildbot to call make repack-l10n-all before uploading.

Comment 18

[Mark Banner (:standard8)]

I believe there's just one more patch I need to do, which is to fix the repack-l10n-all make target to correctly handle shipped-locales (it currently doesn't handle the ja and ja-JP-mac lines) - I've got half a patch for this.

Once I've done that, I've then just got to tweak buildbot to do with the following:

mkdir ../l10n (in linux64_build/build)
cd ../l10n
wget --no-check-certificate http://hg.mozilla.org/build/buildbot-configs/raw-file/CALENDAR_1_0b5_BUILD2/calendar/l10n-calendar-changesets
awk '{ system("hg clone http://hg.mozilla.org/releases/l10n-miramar/" $1); system("hg update -R " $1 " -r " $2); }' l10n-calendar-changesets
cd ../build/objdir-tb/calendar/lightning/
make repack-l10n-all
make upload

(mainly notes for myself).

In theory not too hard to do, hope to get it finished by tomorrow.

Comment 19

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 561286 [details] [diff] [review]
[checked in] Update shipped-locales file

r=philipp

Comment 20

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 561287 [details] [diff] [review]
Create upload target for calendar v2

Same comments as above, but otherwise r=philipp

Comment 21

[Felix Möller]

I think this is closely related to bug #680099.

Comment 22

[Mark Banner (:standard8)]

(In reply to Felix Möller from comment #21)
> I think this is closely related to bug #680099.

Not quite, this is about being able to do actual release builds which are conscious decisions as to when and are tagged etc, that one is about doing nightly builds (which personally, I don't recommend).

Comment 23

[Mark Banner (:standard8)]

Comment on attachment 561286 [details] [diff] [review]
[checked in] Update shipped-locales file

Checked in:

http://hg.mozilla.org/comm-central/rev/11f161a7293d
http://hg.mozilla.org/releases/comm-aurora/rev/07a8a12ce937
http://hg.mozilla.org/releases/comm-beta/rev/5a8ac3d61bc5

Comment 24

[Mark Banner (:standard8)]

Attachment: [checked in] Create upload target, fix repack-l10n-all target

Ok, I can't use all the optimisations in the upload target as the way I want to run this is have the release builds also do the l10n repacks, and so we end up needing to copy lightning-all.xpi to lightning.xpi in a different dir.

Additionally, the issue with the repack-l10n-all command currently is that cat also gives us output like "linux" when hitting the ja and ja-JP-mac lines. I've therefore altered it to awk and this just outputs ja or ja-JP-mac depending on the platform. I've assumed we can default to non-mac when we're not on mac.

This is the last complete patch we'll need. Once this is landed automation will work bar combining the linux xpis into one which can be handled via script.

The buildbot runs I've just done succeeded bar a minor issue with the upload which is fixed in this patch. Hence I think we're good to go for a proper build once we get this landed.

Comment 25

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 561732 [details] [diff] [review]
[checked in] Create upload target, fix repack-l10n-all target


>+	$(PYTHON) $(MOZILLA_DIR)/build/upload.py --base-path $(DIST) \
>+	  $(addprefix $(DIST)/$(MOZ_PKG_PLATFORM)/,$(UPLOAD_FILES))

Base path is $(DIST) and you are adding a prefix that starts with $(DIST). Is this correct?

Otherwise r=philipp

Comment 26

[Mark Banner (:standard8)]

(In reply to Philipp Kewisch [:Fallen] from comment #25)
> Comment on attachment 561732 [details] [diff] [review]
> Create upload target, fix repack-l10n-all target
> 
> 
> >+	$(PYTHON) $(MOZILLA_DIR)/build/upload.py --base-path $(DIST) \
> >+	  $(addprefix $(DIST)/$(MOZ_PKG_PLATFORM)/,$(UPLOAD_FILES))
> 
> Base path is $(DIST) and you are adding a prefix that starts with $(DIST).
> Is this correct?

Maybe surprisingly, yes.

Comment 27

[Mark Banner (:standard8)]

Comment on attachment 561732 [details] [diff] [review]
[checked in] Create upload target, fix repack-l10n-all target

Checked in on all branches:

http://hg.mozilla.org/comm-central/rev/82fd9604e8c7
http://hg.mozilla.org/releases/comm-aurora/rev/12eb54a1b680
http://hg.mozilla.org/releases/comm-beta/rev/bcf680e15221
http://hg.mozilla.org/releases/comm-release/rev/0a19c0eb2533

Note, I think this may still break on windows. We can do that manually for now, but I'll file a follow-up bug to fix it.

Comment 28

[Mark Banner (:standard8)]

One final thing for this bug, set up a new comm-release branch for lightning:

http://hg.mozilla.org/build/buildbot-configs/rev/58af47242a62

(release automation needs this to be set up).

Comment 29

[Worcester12345]

(In reply to Mark Banner (:standard8) from comment #28)
> One final thing for this bug, set up a new comm-release branch for lightning:
> 
> http://hg.mozilla.org/build/buildbot-configs/rev/58af47242a62
> 
> (release automation needs this to be set up).

Cleaning up some old bugs. Thanks for fixing this.

Was this new branch done?

Comment 30

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The bug as such was fixed, today we are using a different combination of branches though. Lightning runs on Thunderbird automation as the bug title suggests.