Extend artifact builds to include Thunderbird
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox68 fixed)
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: darktrojan, Assigned: darktrojan)
References
Details
Attachments
(1 file, 3 obsolete files)
(deleted),
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
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?
Assignee | ||
Comment 2•6 years ago
|
||
CC'ing a bunch of people who might be able to help me here.
Comment 3•6 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #1)
Created attachment 9051612 [details] [diff] [review]
1444220-artifact-mc-1.diffHere's my current m-c patch. With this and some c-c
changeshacks, 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.
Assignee | ||
Comment 4•6 years ago
|
||
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.
Comment 5•6 years ago
|
||
Assignee | ||
Comment 6•6 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #5)
Comment on attachment 9060682 [details] [diff] [review]
1444220-artifact-mc-2.diffReview 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
andproduct
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.
Assignee | ||
Comment 7•6 years ago
|
||
Updated to reflect :nalexander's comments.
Assignee | ||
Comment 8•6 years ago
|
||
Oh, except for the bit about adding comments.
A class comment about what
trust_domain
andproduct
mean here would be helpful.
I'm not actually sure what the trust domain is (or where I got the name from).
Comment 9•6 years ago
|
||
Assignee | ||
Comment 10•6 years ago
|
||
As well as fixing the comments, I did some further refactoring.
Just to prove that it all still works:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9039e6ddd5e0bb66e5bb2b9c4b6c30c5ec7027b9
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=a18a425e6073ee4ad5bba48da5969d540d86d891
Assignee | ||
Comment 11•6 years ago
|
||
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.
Assignee | ||
Comment 12•6 years ago
|
||
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.
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Comment 13•6 years ago
|
||
Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c64f610ccf76
Extend artifact builds to include Thunderbird. r=glandium
Comment 14•6 years ago
|
||
bugherder |
Description
•