[RFC][Technical] Publishing new Experiment Versions

Archives Test Pilot
#1

Currently when an experiment is ready to release a new version of their .xpi file, they send it to me and I upload it to S3 with all the appropriate hashes and redirects and fluff in place. I’d like to get out of the way of new versions and get that automated.

My proposal is:

  1. Experiments have a script at bin/build-add-on.sh which creates a .xpi file in the current working directory and has an exit status of 0 on success.

  2. Experiment maintainers add a hook to their repository which pings Mozilla’s Jenkins instance on commit.

  3. Mozilla’s Jenkins sees the ping, verifies it is on a branch called “production”, updates to the latest code, runs that script, sorts out all the hashes builds an updates.json file, and uploads the .json, .xpi, and /latest/ redirect to S3.

In short, we’d be asking Experiment Maintainers to add a consistently named script (which could just call a gulp task or whatever), use a “production” branch, and add a GitHub hook.

Any comments?

#2

Sounds good to us (Activity Stream)!

I have one concern for the add-on signing, do we need to provide the signing credentials for Jenkins then? we currently have two sets of signing kyes, one for “production” where we sign the add-on manually, the other one for “dev” and “prerelease” where TravisCI does the build-and-sign job.

#3

Hmm, that’s a good point. You’re talking about signing the add-on on AMO, right?

We could make a Test Pilot account on AMO which you could add as an author to the add-on. That way we could give Jenkins access, but remove it when an experiment graduates from Test Pilot. Then you wouldn’t need to share your keys.

#4

Yes, signing the add-on AMO.

I like the plan of having a single signing key for all the experiments if AMO is happy with that :).

Please keep us posted, we’d like to try out this for sure!

#5

Thanks for your comments. Implementation tracking bug is at https://bugzilla.mozilla.org/show_bug.cgi?id=1315033

Cheers!