search

mozilla / addons

☂ Umbrella repository for Mozilla Addons ✨
Other
127 stars 41 forks source link

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

Closed kumar303 closed 3 years ago

kumar303 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

(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 commented 6 years ago

https://github.com/mozilla/addons/issues/5355 would help nicely with the summary (though it still does not solve the category & license)

kumar303 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

stoically commented 4 years ago

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 commented 3 years ago

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 mozilla/addons#6158

LinusU commented 3 years ago

@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 commented 3 years ago

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

eviljeff commented 3 years ago

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 mozilla/addons#6158

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

rubenwardy commented 3 years ago

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 commented 3 years ago

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

The work for this is tracked in https://github.com/mozilla/sign-addon/issues/409

eviljeff commented 3 years ago

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 commented 3 years ago

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

Notes:

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:

Notes:

ioanarusiczki commented 3 years ago

@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 commented 3 years ago

  • 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. mozilla/addons#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 mozilla/addons#8514 about this.