Automate sign & publish .xpi on merges to master

[pdehaan]

I think this is tricky, since you can only sign a single version once, so you'd probably have to bump the manifest version as well, which could leave you with a metric ton of XPI/ZIP files in your manifests directory over time (unless we always overwrite the last generated version).

One of the neat things that activity-stream does is they manually sign+deply builds every 1-2 weeks (1 week during development, 2 weeks after launch) and then we have a blok-dev add-on which gets deployed with every commit. All that is hosted on S3. But at least lets you can choose to install the stable release version, or the Activity Stream Dev v1.1.0-dev-1469471271.

https://github.com/mozilla/activity-stream/blob/master/fabfile.py

[groovecoder]

Is the -dev add-on deployed with every commit signed? What version numbers do they use in the add-on manifest? Can we put a date/time string in the version there?

[lmorchard]

FWIW, we also do this automatically with the main Test Pilot add-on. We have a script that signs every new version, but then re-downloads the existing signed add-on from AMO if it's already been signed. We also append a unique suffix to every add-on version corresponding either to the git commit hash or the release tag.

This all gets handled on Circle CI automatically, and we do deploy a new signed version of the add-on to our dev server in Elastic Beanstalk with every master merge. It gets rolled into the Docker container that we deploy, but you could do it with S3 or something simpler.

Here are some links to code that might help, if you want to steal our process:

https://github.com/mozilla/testpilot/blob/master/circle.yml#L51 https://github.com/mozilla/testpilot/blob/master/addon/package.json#L27 https://github.com/mozilla/testpilot/blob/master/addon/bin/update-version https://github.com/mozilla/testpilot/blob/master/addon/bin/sign

[pdehaan]

"Is the -dev add-on deployed with every commit signed? What version numbers do they use in the add-on manifest? Can we put a date/time string in the version there?"

For Activity Stream, yes the dev add-on is signed:

• /fabfile.py:32-33 shows how we set the manifest's version property to ${version}-dev-${timestamp}
• /fabfile.py:72-73 shows the signing of the add-on using jpm sign --api-key={} --api-secret={}
• /fabfile.py:186 is where we call our package() method, and /fabfile.py:164-173 shows how we grab the key and secret from either a JSON file or environment variables.

Plus then a lot of boto stuff and S3 bucket juggling.

[groovecoder]

I'm working on copying the Test Pilot add-on process.

@lmorchard - the update-version script looks to split the package.json version into versionParts on - character, but I don't see any - character in the package.json version?

[groovecoder]

Putting this work on hold until https://github.com/mozilla/addons-linter/issues/863 is fixed. SDK addons like Test Pilot and Activity Stream seem to run thru a different version-linting gauntlet than Web Extension addons like Blok.

So, I'm un-able to append a unique, hash-based suffix to the version for the signing step.

Though, I could try to increment a patch version counter instead of using the commit hash ... but then I'm not sure how I would get the patch version that Travis generates back into the repo for the next run ...

[groovecoder]

I sent https://github.com/mozilla/addons-linter/pull/891 to fix https://github.com/mozilla/addons-linter/issues/863 so this issue may be un-blocked soon.

[groovecoder]

FWIW, this would have helped avoid #220.