web-ext
web-ext copied to clipboard
Add `web-ext submit` to submit listed add-ons to AMO
Workaround described below β¬οΈ
Is this a bug or feature request?
Feature request
What is the current behavior?
web-ext sign already successfully submits an extension for review, but then it throws an error.
What is the expected or desired behavior?
I don't need instant signing, so if the submission has been successful there should be a way to make it exit with 0.
Suggestions:
$ web-ext sign --submit-only
$ web-ext submit
Version information (for bug reports)
OS X 10.11.6
node --version && npm --version && web-ext --version
v7.2.0 3.10.9 1.8.1
The sign command is intended more for people who self-distribute their add-ons. In your case, why not just use the website? https://addons.mozilla.org/en-US/developers/addon/submit/distribution Is it because you need to put new versions in the review queue frequently? Or just because you'd like to automate the submission process?
Automate all the things! π Here people discussed the Chrome Web Store version, but it also applies to AMO https://github.com/sindresorhus/module-requests/issues/66
Yeah, using web-ext to automatically put a new version in the AMO review queue seems like it could be useful to support automatic deployment (from a git tag or whatever).
I think it would make sense as a new command, such as what you recommended: web-ext submit or web-ext submit-to-amo (to be explicit, maybe).
The good news is that sign-addon already wraps up the signing API pretty well. The bad news is that the API doesn't support submission of listed add-ons in a straightforward way. Using the signing API to submit a listed add-on would be a hack and I'm not sure that it would be so dependable against future API changes. The fact that it works now at all is just by side effect.
We decided to log an informative message about it in web-ext sign but we also let it throw an error to discourage usage. I guess that's a little weird though, heh.
100% this!
I just setup some tasks to automate submitting my extension to the Chrome web store and now I'm working on Firefox (first time ever messing with Firefox Add-ons, so happy about WebExtensions). Looking through the Firefox documentation it wasn't clear to me at all that I could automate sending updates to AMO for an existing add-on... not for self-hosting/self-signing. I even just asked a question on stackoverflow about this.
Even if we added a web-ext submit command, it would not be fully possible to automate submission. The addons.mozilla.org site always requires an editor to review the extension code which is different from the Chrome Store (I believe).
Understood. The current web-ext sign workflow is fine and it's enough for me already. The only issue is the error exit code.
It's still better than packaging it up, opening the browser, visiting AMO, uploading it, etc manually.
agreed . I just want Travis to be able to build and send it off my extension to each respective store. I understand that there's a review process.
I guess for now I'll deal with the error.
@bfred-it are you requiring web-ext from a module? is that possible? or you using child process? Any issues installing web-ext a local dev dependency?
@FranciscoG I'm not, I plan on using it via npm scripts like I'm doing with chrome-webstore-upload-cli on travis
Workaround
I published a 11-lines, temporary web-ext wrapper that filters out the error:
npm install --global web-ext-submit
web-ext-submit
Meant to be used on Travis or GitHub Actions.
https://github.com/fregante/web-ext-submit
Alternative
Or use https://github.com/LinusU/wext-shipit
Hello,
automatic deployment is something really important.
Maybe web-ext submit should also allow publishing source code in zip format?
Thank you @bfred-it
web-ext submit would submit to amo only. If you want the zip you can already use web-ext build
@bfred-it you can add sources to your webextension, to help review
Ah I see what you mean, you have a gulp build step in place. I left a link to the repo in the notes for the reviewer before to show the source.
@guillaumevincent this command uses the Signing API, which only allows the upload of the extension itself. I don't see web-ext allowing the upload of the sources unless there's an API for that. Your best bet would be to include a link to your repo in the zip itself.
I removed the "submit for review" part of this issue title because post-review has landed! In other words, listed add-ons are now published ASAP without needing to pass human review.
This makes something like a web-ext submit feature way more useful but I'll be honest in that we are not able to dedicate any Mozilla resources to adding this feature (as far as I know).
I'm working on a small CLI tool so submit Web Extensions to all major browsers. It currently supports both Chrome and Firefox, using the same workaround that @bfred-it documented...
It's here if anyone wants to use it βΊοΈ
https://github.com/LinusU/wext-shipit
Thanks for posting that @LinusU ! You may also want to check out this issue for the current limitations that web-ext has and how you could workaround them by working directly with the submission API: https://github.com/mozilla/sign-addon/issues/248
It would be really helpful if you could patch sign-addon or web-ext for any new features you may need. I can review and merge any patches in a timely manner. If it's easier, you could patch web-ext just for programmatic support rather than full CLI support.
Would love to contribute programmatic support π
Hopefully, I'll get some more time to look at this next week. In the meantime, I just added Opera support as well, if anyone is interested. Next up: Safari π±
@kumar303 Would you like this as a new command, e.g. web-ext publish, or do you want this to be part of the sign command? To me, it seems like a new command makes the most sense since the fact that a new version of a listed extension will be submitted when using the sign command is more of an unintended side-effect than an actual feature...
web-ext publish or web-ext submit would be good. The sign verb sounds unrelated
Agreed! Making it a new command would be the best approach. Publishing as a side effect of signing is weird and non-intuitive.
Eventually, I think it makes sense to have submit --{listed|selfhosted}. sign can become an alias for submit --selfhosted (for backward-compatibility reasons), but having one command with a mandatory parameter makes it really obvious what you are going to do, vs trying to remember what sign vs submit does.
Would --listed avoid the exit 1? That's the main issue
The proposal from add-on developers in Japan is that the feature fill-in the listing information as follows:
- Summary from
manifest.jsondescription (and, if that's a localized string, looks up the localization) - (Localized) description from _locales/XX/description.txt
- (Localized) release notes from _locales/XX/releasenotes/XX.txt
@birtles thanks for your help on this!
Here are the pre-requisites:
sign-addonneeds https://github.com/mozilla/sign-addon/issues/253 so thatweb-ext submitcan share code with howweb-ext signalready works- The AMO API needs https://github.com/mozilla/addons/issues/5348 to support submitting new listed add-ons
Just to confirm. We can submit new versions of pre-existing addons on AMO using the current upload endpoing even now, but we can't submit it with any release notes altogether, right?
As for 'submit' command for web-ext, we should support submitting new addons to avoid confusion, but we can probably defer it later? Also it seems to me that people here (@bfred-it, @LinusU) are just mentioning to submit new versions without release note. @guillaumevincent is mentioning that it would be nice that submit command can upload the source code of the uploading version.
Anyway, it seems to me that we can do them step by step;
- Create web-ext submit command to upload a new version of pre-existing addons without release note and its source code
- Modify submit command to upload with release note and source code once AMO extends the upload endpoint (or new endpoint?)
- Modify submit command to be able to upload a new addon once AMO has the new API
Please correct me if I am misunderstanding something.
@hiikezoe
That seems exactly it to me.
So am I understanding correctly that automatic releases of new versions (in any way) is blocked by the API not supporting uploading source code? And the API is not open source? I am completely okay with writing my own script that talks to the API (and contributing it to the community), but it seems like there is no way currently - as I read the Add-on policies, if the Add-on contains bundled, minified or otherwise machine-generated code, the source code must be uploaded. What extension is not bundled/minified/machine-generated nowadays?
but I'll be honest in that we are not able to dedicate any Mozilla resources to adding this feature (as far as I know).
@kumar303 would it be possible to at least get some Mozilla resources to extend the API for uploading sources?
Are there other workarounds? I would be fine with making the source public, but I wouldn't know how to link to it when using the signing API. Is it possible? Can we omit source submission if the extension is open source? What about release notes, is it possible to submit those through the API?
Since the above workaround does not seem to support uploading sources and adding release notes, I wrote a semantic-release plugin semantic-release-firefox (it could run without semantic-release though, happy to refactor if there is interest). It uses Puppeteer to upload the XPI and sources through the AMO website in a headless Chrome. We use it to automatically release sourcegraph/browser-extensions
So am I understanding correctly that automatic releases of new versions (in any way) is blocked by the API not supporting uploading source code? And the API is not open source?
This is crazy, every time I need to upload manually my source code to AMO web site. Mozilla just add a URL field and allow automatic publication. We are in 2018, nobody wants to do manually publication.
Do you need some help somewhere? It should not be so complicated
Yet another tool for this task; https://www.npmjs.com/package/firefox-extension-deploy
I found it simplest to set up.