If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[client] improve handling of extensions in tinderbox

RESOLVED FIXED

Status

Webtools Graveyard
Tinderbox
RESOLVED FIXED
10 years ago
3 years ago

People

(Reporter: Robert Kaiser, Assigned: Robert Kaiser)

Tracking

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

10 years ago
Created attachment 283707 [details] [diff] [review]
handle extension more flexibly in tinderbox

I've tried to create a tinderbox for venkman to produce regular [nightly] packages for it and realized tinderbox can be used for this quite nicely for the most part.

Using the extensions/ dir created in dist/bin as $BinaryName for it is a hack of some sort but works out nicely as long as we don't end up pointing $Settings::DistBin somewhere else because we happen to be on a mac, so I coded up a small change to make this case work.

When it comes to uploading, we already have some code in post-mozilla-rel.pl to upload Lightning and xforms specifically - I figured if we replace this with generic handling, we reduce code, make stuff clearer and are able to handle cases like mine as well.
I ended up with adding to options to config, one giving a glob pattern to copy from xpi-stage/ to our upload dir, and one for putting the extension in platforms-xpi/ subdirs or not.

This works fine on my mac tinderbox with both normal trees that build SeaMonkey (where this does nothing) and on the venkman build listed on MozillaTest atm that has |$ReleaseExtension = "venkman*.xpi";| set in tinder-config.pl
Attachment #283707 - Flags: review?(preed)
(Assignee)

Updated

10 years ago
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 1

10 years ago
Oh, I forgot, to make the Lightning tinderboxen do the same thing as they are now with this patch, we'd need to add
$ReleaseExtension = "lightning*.xpi";
$ReleaseExtensionPlatform = 1;
to their tinder-config.pl files - similar things need to be done if we happen to have boxes somewhere that actually use the xforms stuff, $ReleaseExtension can probably be set to plain "xforms.xpi" there.

Unless the build process of the extension itself needs it, we could even go as far as to have the tinderboxen build only Lightning and no complete Thunderbird with this patch.
(Assignee)

Updated

10 years ago
Summary: [client] improve handing of extensions in tinderbox → [client] improve handling of extensions in tinderbox
(Assignee)

Comment 2

10 years ago
Comment on attachment 283707 [details] [diff] [review]
handle extension more flexibly in tinderbox

Apparently, bug 410922 also covers at least part of this, clearing review for now.
Attachment #283707 - Flags: review?(mozpreed)
(Assignee)

Comment 3

10 years ago
I've had a conversation with Philipp who did work on bug 410922 and we agreed that the clean solution fitting all of us would be to have the following settings:
@ReleaseExtensions, which is empty be default and can set to a list that even can contain wildcards, e.g. ('lightning*.xpi', 'gdata-provider.xpi');
$ReleaseExtensionSubdir, which is an empty string by default and makes us use the platform subdirs. If set to a non-empty string, that subdir is created and used for extensions upload. I propose that a value of "." should use the main FTP directory, not creating a subdir for extensions.

The patch for bug 410922 basically implements that (though I'm not sure how well wildcards and the "." value have been tested yet), we'll extend the work from that bug in here to also cover the cases I have been targeting here.
(Assignee)

Updated

10 years ago
Depends on: 410922
(Assignee)

Comment 4

10 years ago
Created attachment 296649 [details] [diff] [review]
patch v2: improved handling of extensions in tinderbox

This new patch does the following:

1) Allow the use of the extensions/ dir created in dist/bin as $BinaryName so that an extensions-only tinderbox can work.

2) Remove explicit handling of xforms in favor of the new generic mechanism for extensions, that includes handling of an eventual os2-xpi/ directory for those.

3) Handle wildcards when determining if an extension to upload has been found.

4) Only create $extensionStageDir when it doesn't exist yet.

5) Remove the -r option from the cp command for extensions.


We'll need to patch 1.8 branch Firefox tinderbox configs for still handling xforms upload, I'll attach it in a second.
Attachment #283707 - Attachment is obsolete: true
Attachment #296649 - Flags: review?(ccooper)
(Assignee)

Comment 5

10 years ago
Created attachment 296652 [details] [diff] [review]
patch Firefox 1.8 branch tinderbox configurations

This patches the Firefox tinderbox configurations for 1.8 branch to still upload xforms XPIs. Note that I'm cleaning up double-use of the $BuildXForms veraible in those tinder-config files as well.
Attachment #296652 - Flags: review?(ccooper)

Comment 6

10 years ago
Comment on attachment 296652 [details] [diff] [review]
patch Firefox 1.8 branch tinderbox configurations

Good catch with the double definition of XForms.
Attachment #296652 - Flags: review?(ccooper) → review+

Updated

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

Comment 7

10 years ago
Checked in both patches. From what I see, at least the Linux 1.8 box still uploads XForms and everything stayed green :)
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.