Firefox/Go Faster/Release Pipeline: Difference between revisions
(→Shipping Infrastructure: Add caveat regarding number of people assigned to the "Shipping Infra") |
(Add a proposal.) |
||
| Line 1: | Line 1: | ||
== Testing | CI == | == Testing | CI == | ||
== Proposal == | |||
The initial pipeline should be very lightweight. Tests/Builds can be run via a TaskCluster GitHub bridge. Where pull requests trigger tests, and tagged pushes trigger builds and an attempt to upload to whatever service hosts the addon packages. A/B testing and allowing public access to addons will need to be handled by hand after this process is completed. | |||
===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." | |||
== Bugs == | |||
(mrrrgn) [https://bugzilla.mozilla.org/show_bug.cgi?id=1158272 TC->GitHub bridge] | |||
== Release Triggering == | == Release Triggering == | ||
Revision as of 16:08, 7 July 2015
Testing | CI
Proposal
The initial pipeline should be very lightweight. Tests/Builds can be run via a TaskCluster GitHub bridge. Where pull requests trigger tests, and tagged pushes trigger builds and an attempt to upload to whatever service hosts the addon packages. A/B testing and allowing public access to addons will need to be handled by hand after this process is completed.
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."
Bugs
(mrrrgn) TC->GitHub bridge
Release Triggering
see: ???
Developers will need a system for notifying us when they are ready for a release to be rolled out. We also need procedures for things like tagging.
- Could this be a self-serve UI? - Could this be related to .taskclusterrc and tied to either release tagging or pinning to a revision?
Shipping Infrastructure
See: mrrrgn, JP, ??? (we'll probably need help from other RelEng members)
We could use AMO or Balrog for hosting addons.
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.