Confirmed users
656
edits
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
With the new addon signing requirement, working with | With the new addon signing requirement, working with addons in mozilla-central gets a little more complicated. Anytime an addon is modified, it will need to be version bumped and re-signed. Yes, even if you just want to add a dump statement to debug a try run. Yuck! This guide is intended to provide all the information you need to work with signed addons in mozilla-central. At first, signing will largely by a manual process, but eventually tooling will improve and the process will get easier. | ||
== Prerequisites == | == Prerequisites == | ||
1. Obtain the [https://mana.mozilla.org/wiki/display/ateam/Signing+Extensions+in+Tree signing keys]. You'll need LDAP to access them. If you do not have LDAP, unfortunately you will not be able to sign | 1. Obtain the [https://mana.mozilla.org/wiki/display/ateam/Signing+Extensions+in+Tree signing keys]. You'll need LDAP to access them. If you do not have LDAP, unfortunately you will not be able to sign addons in mozilla-central. | ||
2. Install jpm by following the [https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/jpm official instructions]. Make sure you have at least version 1.0.5 by running: | 2. Install jpm by following the [https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/jpm official instructions]. Make sure you have at least version 1.0.5 by running: | ||
$ jpm --version | $ jpm --version | ||
== Signing an | == Signing an Addon == | ||
You've made changes to an | You've made changes to an addon, and want to check them into the tree. But automation won't pick your changes up until you've signed it. Here's what you need to do step by step. | ||
1. Bump the version number in install.rdf. It's not possible to sign the same version twice, so each change requires a version bump. If appropriate, you may want to add a new minor version number (e.g x.y.z). | 1. Bump the version number in install.rdf. It's not possible to sign the same version twice, so each change requires a version bump. If appropriate, you may want to add a new minor version number (e.g x.y.z). | ||
2. If your | 2. If your addon is not generated by the build, skip to step 3. Otherwise, you'll first need to build your addon with `mach build`. After building, cd to the final addon directory (usually in $OBJDIR/dist/xpi-stage). | ||
3. Pack the addon into an xpi. An xpi file is simply a renamed zip file. For example, you could use: | 3. Pack the addon into an xpi. An xpi file is simply a renamed zip file. For example, you could use: | ||
| Line 22: | Line 22: | ||
5. If validation failed, open the link to see what needs to be changed. If it was successful, you should have a new .xpi file in your working directory. If appropriate, move and/or rename this file to whatever the relevant automation is expecting. | 5. If validation failed, open the link to see what needs to be changed. If it was successful, you should have a new .xpi file in your working directory. If appropriate, move and/or rename this file to whatever the relevant automation is expecting. | ||
6. Add the signed | 6. Add the signed addon to your commit: | ||
$ hg add my-addon-signed.xpi | $ hg add my-addon-signed.xpi | ||
$ hg commit -m "Bug 1234567 - Update my-addon.xpi" | $ hg commit -m "Bug 1234567 - Update my-addon.xpi" | ||
| Line 36: | Line 36: | ||
== How to Avoid Addon Signing == | == How to Avoid Addon Signing == | ||
Signing | Signing addons can potentially be a pretty big pain. But with a bit of effort, that pain can be avoided. | ||
=== Don't use Addons === | === Don't use Addons === | ||