Firefox/Go Faster/Release Pipeline: Difference between revisions

Status update
(Add name to proposal.)
(Status update)
Line 12: Line 12:
A/B testing and allowing public access to addons will need to be handled by hand after this process is completed.
A/B testing and allowing public access to addons will need to be handled by hand after this process is completed.
===Questions===
===Questions===
* Can we get away with doing only Linux initially? There is no good solution for Mac/Windows via TaskCluster at the moment and buildbot changes are not generally within the realm of "light weight."
* Can we get away with doing only Linux initially? There is no good solution for Mac/Windows via TaskCluster at the moment and buildbot changes are not generally within the realm of "light weight." | No, we'll need to use the TaskCluster generic worker to support Windows first and foremost.


===Pieces Needed===
===Pieces Needed===


* A test project: what will be trying to ship? "hello?"
* A test project: This will be Hello (see: rhelmer, standard8, dmose, abr)


* TaskCluster -> GitHub bridge: this will allow us to set up automated testing and builds very quickly.  ''note'' why not Autolander? It only handles pull requests, so it could provide automated testing, but would not allow us to handle automated builds.
* TaskCluster -> GitHub bridge: this will allow us to set up automated testing and builds very quickly.  ''note'' why not Autolander? It only handles pull requests, so it could provide automated testing, but would not allow us to handle automated builds.
Line 40: Line 40:
See: mrrrgn, JP, ??? (we'll probably need help from other RelEng members)
See: mrrrgn, JP, ??? (we'll probably need help from other RelEng members)


We could use AMO or Balrog for hosting addons.  
We should use Balrog for hosting addons due to client side requirements.


===Balrog Needed Features / Status: ===
===Balrog Needed Features / Status: ===
===AMO Needed Features / Status: ===
There are some difficulties around using it, but it seems possible to create a working prototype without actually changing its code base (though it will require a workflow with human intervention).
tl;dr: We'll need a special "GoFast" addon type with improved permissions, and a few REST endpoints (instead of crufty old web forms).
====Ability to host multiple addon versions at the same time.====
Status: This is supported but only for "listed" [public] addons.
====Ability to partially roll out updates====
Status: The AMO system relies on manifests which map addon versions to supported platforms. Normally users will always get the latest version, but it is possible to package addons with a custom "updateURL" which firefox will use to search for new versions.
We will also need to build our own service for managing version manifests. The service could be a proxy (more flexible) or a web app (easier to manage) depending on what our needs seem to be as the project progresses.
To use updateURL with a listed update, we will need administrator intervention.
====API for uploading addons====
This is currently a multi-part web form. This will need to be turned into an API asap.
====Signing Addons====
Signing happens just after an App is uploaded to AMO. Currently addons will be put into a "review queue" with a three month backlog. We can bypass this via an administrator's intervention.
78

edits