Currently, our releases tend to be either the initial code drop for an esr release, or the last version where we needed to fix up something embedding-specific (and so bothered to do a release.) That means that many embedders end up using the full tree rather than our releases, so that they'll get security updates. We really need to have some process or procedure set up to copy over spidermonkey packages corresponding to dot releases.

(In reply to Steve Fink [:sfink] [:s:] from comment #0) > We really need to have some process or procedure set up to copy over > spidermonkey packages corresponding to dot releases. Would it make sense to ask our release management team if we can add any custom process for building / copying to the proper locations the releases of SpiderMonkey standalone tarballs? (cc J. Cristau)

Speaking with Johan (:jlorenzo) about this topic, apparently we should have something to make this possible within the sources, starting with beta 59.

Starting Firefox 59, Firefox releases should be all defined in-tree under taskcluster/**. The process you guys need should be very similar to what will be present for Firefox. This means, you can copy and tweak our existing jobs to fit your needs, and we'd be happy to review. More precisely, from the discussion I had with :nbp, you guys may need these steps: 1. build. This is something you can work on today. For instance, Firefox builds for Linux are defined at [1]. The build task you produce and upload as Taskcluster artifacts: * an unsigned build * a checksum of your build See [2] as an example. 2. upload to archive.mozilla.org (aka "beetmover"). This part is the one currently ironed out on Firefox. We have something already defined for Fennec[3]. In addition to the Taskcluster task definition, you will require a specific type of Taskcluster worker called beetmover workers. This worker knows how to upload your artifacts. In the Firefox world, this is done by defining this YAML template[4]. You also need to tell beetmover workers what credentials you're using to push to archive.mozilla.org[5]. I assume you are using Amazon S3, in which case, you should ask CloudOps for a new set of credentials. They will be used by the workers alone. For security reasons, we may not want to use the existing instances of Firefox beetmover workers. The rationale is: if for some reason, somebody crafts a SpiderMonkey artifact that exploits beetmover workers, then it can't be used to ship a rogue Firefox. Releng will handle the deployment and the configuration of these workers (just like it's done for Thunderbird, in bug 1421062). To sum up, step 2 is about: defining a task understandable by your instance of beetmover worker. Regarding signing, I see your builds aren't signed at the moment[6]. Introducing signing is doable, but require to generate new GPG keys, and update our signing chain to support/lock such signing to your type of artifacts. :nbp told me this isn't a priority at the moment, you would just prefer to produce the same output as you used to. Finally, you will need to configure when you want these 2 steps to start. :nbp told me you plan to ship on every Firefox release (off mozilla-release or mozilla-esr*). In this case, you will want to create a new type of Taskcluster decision task. For Firefox, such a task will land in 59. I'll give you more details once it does. I hope this help understanding the moving parts of this project. Please let me know if you have any question or if I can provide more context. [1] https://searchfox.org/mozilla-central/rev/9d920555ec81f1c9d4b7fa3b08e23eb88efb60e1/taskcluster/ci/build/kind.yml, https://searchfox.org/mozilla-central/rev/9d920555ec81f1c9d4b7fa3b08e23eb88efb60e1/taskcluster/ci/build/linux.yml, https://searchfox.org/mozilla-central/rev/9d920555ec81f1c9d4b7fa3b08e23eb88efb60e1/taskcluster/taskgraph/transforms/build.py [2] https://tools.taskcluster.net/groups/SE7OHt7mS_qc5ytBY5fPtA/tasks/GrUUuTjyRFejighFG7IizQ/runs/0/artifacts [3] https://searchfox.org/mozilla-central/rev/9d920555ec81f1c9d4b7fa3b08e23eb88efb60e1/taskcluster/ci/beetmover-cdns/kind.yml#9 [4] https://github.com/mozilla-releng/beetmoverscript/blob/dc2f8cdd19ef7dd1e5a34e1c62cecd970c5d410d/beetmoverscript/templates/firefox_candidates.yml [5] https://github.com/mozilla-releng/beetmoverscript/blob/dc2f8cdd19ef7dd1e5a34e1c62cecd970c5d410d/config_example.json#L45 [6] https://archive.mozilla.org/pub/spidermonkey/releases/45.0.2/