Closed Bug 1444220 Opened 7 years ago Closed 6 years ago

Extend artifact builds to include Thunderbird

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox68 fixed)

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: darktrojan, Assigned: darktrojan)

References

Details

Attachments

(1 file, 3 obsolete files)

The build code can be made to download Thunderbird artifacts instead of Firefox artifacts by changing the relevant strings [1]. This bug is about doing so in a way that doesn't also break everything for Firefox. [1] https://gist.github.com/darktrojan/4e24e58658a682a9d34be408dec7c852#file-m-c-diff
Component: Build Config → General
Product: Thunderbird → Firefox Build System
Attached patch 1444220-artifact-mc-1.diff (obsolete) (deleted) — Splinter Review

Here's my current m-c patch. With this and some c-c changes hacks, I have a working artifact build.

Firefox people, do you have any suggestions as to how I might work this in, in a way that would be acceptable?

CC'ing a bunch of people who might be able to help me here.

Assignee: nobody → geoff
Status: NEW → ASSIGNED

(In reply to Geoff Lankow (:darktrojan) from comment #1)

Created attachment 9051612 [details] [diff] [review]
1444220-artifact-mc-1.diff

Here's my current m-c patch. With this and some c-c changes hacks, I have a working artifact build.

Firefox people, do you have any suggestions as to how I might work this in, in a way that would be acceptable?

The artifacts.py stuff is fine -- just generalize it such that the appname and the index is part of the configuration in mach artifact (which is where you have access to the build config). Default it to the Firefox case and I see no reason we can't land that.

Attached patch 1444220-artifact-mc-2.diff (obsolete) (deleted) — Splinter Review

I doubt this is quite what you had in mind, but it's taken me so long to get this far that I might as well post it. My changes feel a bit hacky, but they do work.

Attachment #9051612 - Attachment is obsolete: true
Attachment #9060682 - Flags: feedback?(nalexander)
Comment on attachment 9060682 [details] [diff] [review] 1444220-artifact-mc-2.diff Review of attachment 9060682 [details] [diff] [review]: ----------------------------------------------------------------- Honestly, this looks way better than I expected it too; I'm pleased at how nicely the assumptions baked into this code -- and there are many -- generalize smoothly. It's not particularly hacky but I would prefer to avoid the blanket substitution. :glandium, do you want to see different things? Would you take this more-or-less as is? ::: python/mozbuild/mozbuild/artifacts.py @@ +125,2 @@ > > class ArtifactJob(object): A class comment about what `trust_domain` and `product` mean here would be helpful. @@ +473,5 @@ > 'plugin-container.app/Contents/MacOS/plugin-container', > 'updater.app/Contents/MacOS/org.mozilla.updater', > # 'xpcshell', > 'XUL', > + 'thunderbird', It would be nice if this was in the Thunderbird* hierarchy you create below. @@ +586,5 @@ > +class LinuxThunderbirdArtifactJob(LinuxArtifactJob): > + trust_domain = 'comm' > + product = 'thunderbird' > + > + package_artifact_patterns = { This isn't the end of the world, but it would also be nice to use the substitution `{product}/XUL.dylib` and then make ``` @property def package_artifact_patterns(self) { p.format(product=self.product) for p in ... } ``` That is, rather than substitute a special keyword, bake the keyword into the definitions and then process the definitions depending on the product.
Attachment #9060682 - Flags: review?(mh+mozilla)
Attachment #9060682 - Flags: feedback?(nalexander)
Attachment #9060682 - Flags: feedback+

(In reply to Nick Alexander :nalexander [he/him] from comment #5)

Comment on attachment 9060682 [details] [diff] [review]
1444220-artifact-mc-2.diff

Review of attachment 9060682 [details] [diff] [review]:

Honestly, this looks way better than I expected it too; I'm pleased at how
nicely the assumptions baked into this code -- and there are many --
generalize smoothly. It's not particularly hacky but I would prefer to
avoid the blanket substitution.

:glandium, do you want to see different things? Would you take this
more-or-less as is?

::: python/mozbuild/mozbuild/artifacts.py
@@ +125,2 @@

class ArtifactJob(object):

A class comment about what trust_domain and product mean here would be
helpful.

@@ +473,5 @@

             'plugin-container.app/Contents/MacOS/plugin-container',
             'updater.app/Contents/MacOS/org.mozilla.updater',
             # 'xpcshell',
             'XUL',
  •            'thunderbird',
    

It would be nice if this was in the Thunderbird* hierarchy you create below.

Yes, I did that at first and then changed it to this way figuring it looked tidier. I guess since I've done Linux and Windows by overriding I should do Mac the same way.

@@ +586,5 @@

+class LinuxThunderbirdArtifactJob(LinuxArtifactJob):

  • trust_domain = 'comm'
  • product = 'thunderbird'
  • package_artifact_patterns = {

This isn't the end of the world, but it would also be nice to use the
substitution {product}/XUL.dylib and then make

   @property
   def package_artifact_patterns(self) {
        p.format(product=self.product) for p in ...
   }

That is, rather than substitute a special keyword, bake the keyword into the
definitions and then process the definitions depending on the product.

Again, I thought about doing it that way but it made the for loop really ugly. Using a property is a good idea way to fix that, that I hadn't considered.

Attached patch 1444220-artifact-mc-3.diff (obsolete) (deleted) — Splinter Review

Updated to reflect :nalexander's comments.

Attachment #9060682 - Attachment is obsolete: true
Attachment #9060682 - Flags: review?(mh+mozilla)
Attachment #9061215 - Flags: review?(mh+mozilla)

Oh, except for the bit about adding comments.

A class comment about what trust_domain and product mean here would be helpful.

I'm not actually sure what the trust domain is (or where I got the name from).

Comment on attachment 9061215 [details] [diff] [review] 1444220-artifact-mc-3.diff Review of attachment 9061215 [details] [diff] [review]: ----------------------------------------------------------------- ::: python/mozbuild/mozbuild/artifacts.py @@ +599,5 @@ > + trust_domain = 'comm' > + product = 'thunderbird' > + > + _package_artifact_patterns = { > + p.replace('firefox', 'thunderbird') What was the point of the whole '{product}' thing if you just .replace()? @@ +1351,5 @@ > 'revision': revision}, > 'Will only accept artifacts from a pushhead at {revision} ' > '(matched revset "{revset}").') > # Include try in our search to allow pulling from a specific push. > + pushheads = [(list(self._candidate_trees) + ['try'], revision)] don't you want try-comm-central instead of try?
Attachment #9061215 - Flags: review?(mh+mozilla) → feedback+
Attached patch 1444220-artifact-mc-4.diff (deleted) — Splinter Review
Attachment #9061215 - Attachment is obsolete: true
Attachment #9062111 - Flags: review?(mh+mozilla)

Regarding the list of candidate trees, comm-beta and comm-esr68 will definitely be useful in the future, should I just add them now? I see that neither release or ESR trees are listed for Firefox builds, but I guess that's because there's not much going on there for 99.9% of Firefox developers.

Adding .shippable is currently breaking the OS X Thunderbird builds, but I think we've still got issues with that on "real" builds, so I'm ignoring it.

Attachment #9062111 - Flags: review?(mh+mozilla) → review+
Keywords: checkin-needed

Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c64f610ccf76
Extend artifact builds to include Thunderbird. r=glandium

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: