Upload/submit a new listed add-on version through the API

[kumar303]

This API feature would support the highly requested web-ext submit command and improve automation abilities for add-on developers.

In addition to the existing upload endpoint, we want an endpoint (the same one, maybe) that would allow us to upload a new add-on in a listed state.

[diox]

I think the 3 requirements are categories, summary and license, so we'd need to add that. But presumably we'd also want to be able to set any of the fields available through devhub submission and not just those.

[birtles]

The request we've had from add-on developers here in Japan is to be able to set the summary, description, and release notes, and to be able to do it for multiple locales too.

On the add-on developer experience team we're keen to see this happen soon and are prepared to put resources behind the web-ext bits. Please let me know if there's anything else we can do to help.

[eviljeff]

(I'm certain we have an existing issue asking about this but I can't find it)

I'd prefer we implement POST/PATCH on the /addon/ API endpoint rather than attempt to hack something (more) onto the signing endpoint.

[diox]

#5355 would help nicely with the summary (though it still does not solve the category & license)

[kumar303]

I'm certain we have an existing issue asking about this

I thought so too but I couldn't find one. I'm sure it will turn up 😄

[kumar303]

we're keen to see this happen soon and are prepared to put resources behind the web-ext bits

@birtles this is great news! I think the web-ext / sign-addon patches that are needed may be easier for your team to dive into. The API patch may be harder but I'm hoping that the AMO team will have some time to help you out. They can certainly help get you up and running if you'd like to tackle it.

As always, feel free to ask questions in #amo on IRC, time zone synchronization permitting. For async questions, you can reach out to dev-addons but I'd suggest cc'ing @muffinresearch so he can make sure someone from the team is checking it (that list also has discussions about extension development).

[birtles]

Thanks, that's very helpful. I think hacking on the AMO API is pretty far outside our usual area of work (we're basically platform engineers) so let me see if there are any existing plans to work on that in the AMO team before we consider taking it on.

[stoically]

Would be useful to declare the compatible apps when submitting Add-on as well, since currently it always adds Firefox and Firefox Android as compatible.

[rubenwardy]

Maybe I misunderstand this issue, but submitting a new add-on is an infrequent task that should be low priority when it comes to adding an API

Much much higher priority should be allowing submitting updates to existing add-ons. I have a CI process that runs when I tag a release, but I'm unable to deploy the release to AMO due to #6158

[LinusU]

@rubenwardy it was a while since I worked on this now, but I was automatically submitting updates to a web extension using the following library: https://github.com/LinusU/wext-shipit

[MihaiTabara]

This may be random but TIL this issue may be paving the way for #7908 which is very exciting to hear for us in RelEng/RelMan teams. Just wanted to drop a thank you note for this :)

[eviljeff]

Maybe I misunderstand this issue, but submitting a new add-on is an infrequent task that should be low priority when it comes to adding an API

Much much higher priority should be allowing submitting updates to existing add-ons. I have a CI process that runs when I tag a release, but I'm unable to deploy the release to AMO due to #6158

this will be the base work that will eventually allow you to submit/manage everything about an add-on via the API.

[rubenwardy]

That's great to hear, thanks for clearing it up!

rubenwardy it was a while since I worked on this now, but I was automatically submitting updates to a web extension using the following library: LinusU/wext-shipit

@LinusU Unfortunately, this uses web-ext so probably doesn't support uploading source .zips I'm guessing?

[willdurand]

@LinusU Unfortunately, this uses web-ext so probably doesn't support uploading source .zips I'm guessing?

The work for this is tracked in mozilla/sign-addon#409

[eviljeff]

The basic patch for this issue is now merged and will be available on addons-dev shortly. It won't be available on AMO prod until it's been tested and enough of the missing functionality is implemented. https://github.com/orgs/mozilla/projects/174 will track the issues.

[ioanarusiczki]

@eviljeff
I tested with a dummy extension and a static theme using JWT Authentification like this:

• POST with api/v5/addons/upload/ to get the uuid. At this step upload file and specification of the channel is required.
• POST /api/v5/addons/addon/ to create a new extension/static theme. Depending on the channel specified into the first step, the addons are created - 201 status. It needs the JSON: {"categories": {"firefox": ["other"]}, "version": {"upload": "e8c7c1dbfe794f9aa920b079097b947a", "license": 18}}

Notes:

• when there's no "summary" the submission is created but it looks incomplete in dev hub where it can be resumed
• a submission is created with any valid license id from admin tools, so I could add for an extension a license id that belongs to themes (I refer to the list of licenses displayed for themes in dev hub)
• I get a 201 created status when no category is mentioned, "firefox": [], in this case the submission can be resumed from dev hub.

A new version of an extension can be submitted and it can be listed or unlisted, it does not matter what channel used the previous version:

• it requires the uuid generated with POST api/v5/addons/upload/
• POST with api/v5/addons/addon/620780/versions/, JSON {"upload": "04e2361ad6614f44ae705e75b2b1a589", "license":18}

Notes:

• For a new unlisted version the license is required.

[ioanarusiczki]

@eviljeff To add my conclusion, I think that so far this works as expected but I've added the notes as they could probably help.

I verified this with Postman - AMO dev.

[eviljeff]

• when there's no "summary" the submission is created but it looks incomplete in dev hub where it can be resumed

• I get a 201 created status when no category is mentioned, "firefox": [], in this case the submission can be resumed from dev hub.

• For a new unlisted version the license is required.

The logic around required metadata is a bit wrong currently - we want to strictly require summary, license, and categories for listed versions, but have them be optional for unlisted. #8515 aims to redress this in

• a submission is created with any valid license id from admin tools, so I could add for an extension a license id that belongs to themes (I refer to the list of licenses displayed for themes in dev hub)

I've added a comment to #8514 about this.