1208561 - Upload new version of add-on API

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: API, defect, P1)

Description

[Mark Striemer [:mstriemer]]

Add a new API endpoint to support uploading a new version for an existing add-on. This endpoint will accept the add-on file and start validating it. Its URL should be namespaced for our new API and should be able to be reused in our rewrite.

It will probably look something like this:

PUT /api/v3/addons/my-addon/1.2.3/

{
  "automatic": "always",
  "add-on": "blob or form-data upload",
}

automatic: "always", "never", "allow" - some mechanism to prevent hitting the manual queue if you don't want to and are unlisted
add-on: upload the add-on somehow, we should probably use form-data but base64 blob might be handy

* If an add-on is being automatically validated or is in the manual review queue issuing a PUT to the same version should return 423 LOCKED (or similar).
* If the add-on has passed its validation (automatic or manual) then issuing a PUT should return 409 CONFLICT (or similar).
* If an add-on has failed its validation (automatic or manual) then issuing a PUT should be allowed (until a new version is submitted again).

Issuing a GET to this URL should give the status for the upload but that's another bug.

Comment 1

[Mark Striemer [:mstriemer]]

We should key off of the add-ons guid instead of its slug since the guid needs to be unique and is stored in the install.rdf file.

Comment 2

[Mathieu Agopian [:magopian]]

So the PR is https://github.com/mozilla/olympia/pull/817, not sure if I should discuss it there (on github) or here.

Let's try here: do we want to enforce that a given version submitted is "greater than" the existing versions? I believe currently we don't care: when we ask for an update, we only order the versions by submission date, not version number. We do have some mechanism in place to help with that, as we also store (most of the time?) the "version_int". I'm just not sure we should bother with that. Not everybody is using semver nor "logical" version numbering.

On a slightly unrelated note, I'm not sure we want to keep the "Version" model at the end of the day. I don't feel it's of great use, and is mostly a pain to maintain, enforce, make sense of, and overall confusing. So the less work we do for Versions, the easier it'll be to get rid of it (if we do end up getting rid of it: discussed in https://mail.mozilla.org/pipermail/dev-addons/2015-October/000068.html).

I believe "Return 403 FORBIDDEN if the add-on exists but you don't own it." should be in the "TODO" part of the PR.

Comment 3

[Mathieu Agopian [:magopian]]

Is this bug about 1/ creating a new version (uploading a file for a new version of an add-on), or for 2/ uploading a new file to an existing version?

If it's 1/, then I don't think we want the version number (or version PK) in the URL. It should already be in the manifest, and it's the version we're currently using when creating a new version.

On a side note, in the PR it's using the version PK, in this bug it's talking about the version number.

Comment 4

[[github robot]]

Commits pushed to master at https://github.com/mozilla/olympia

https://github.com/mozilla/olympia/commit/4037c027a936ccfcfd60d62e1560fe0bed9063c1
Upload a new version for an add-on API (bug 1208561)

https://github.com/mozilla/olympia/commit/82d8c420a4e36af6c56b0f182af96ed2f6ddf3b0
Merge pull request #817 from mstriemer/upload-version-api-1208561

Upload a new version for an add-on (bug 1208561)

Comment 5

[Mark Striemer [:mstriemer]]

No status info yet but you can upload an add-on and if it is unlisted and passes validation it will get auto-signed.