APIs snapcraft push and release to branded stores

What APIs are available to clients such as snapcraft to be able to push and release to branded stores?
Would we see all the snaps related to our account-id or will these also be branded store filtered through the API?

As I understand it (@cprov and I discussed this last week, but it’s a little murky), snap IDs are associated with a given brand store. Once the snap ID is established, snapcraft can use the current API to push the snap, and it’ll go to the brand store.

The problem is, snap IDs are not established when the name is registered, but upon the first snap upload. Which means the snap must be uploaded at least once via the brand store web interface before snapcraft can be used.

Hi! Let me shed some light into this.

Snap IDs (and snap names) are defined across stores, they are not “per store”. This means that if the name “firefox” is taken and belongs to a snap published in the main snap store, it can’t be re-registered to be used in another brand store.

So, at the time a snap name is being registered, there is a change the owner will not know in which store the snap will be published in, so is tricky to make the binding at that time. Even if the publisher would know with certainty which store the snap will be published in, allowing him/her to set the store while registering the name would cause the confusion (or assumption) that the same name can be registered against a different store.

I’m working right now in providing support for our snap push API endpoint so snapcraft can send the desired store on the first push. For subsequent pushes, the same store as the initial store will be used automatically, and if snapcraft specifies a different store, the handler will return an explicit error code.

The action of releasing is store-independent, because release is done within the store the snap has been pushed to. A publisher can not, at this time, choose to release to a different store.

@sergiusens what do you think of this proposal?

1 Like

I think this is a first good step. We can then do something like snapcraft push <snap-file> [--store-id <ID>]

A second step (if not done already) would be for the snaps returned as part of the account info to add the store they belong to so that snapcraft list-registered returns the list of snaps with the added information.

The server side for this change is ready and available in production. The snap push API would accept and handle a store ID sent via the store header. A very simplistic diff of the code in snapcraft is:

(but it needs tests and better error handling).

@sergiusens what do you think?

This change actually broke our checkbox-plano (https://dashboard.snapcraft.io/dev/snaps/6160/) daily builds.
Since it’s a snap from a brand store, the usual command:

snapcraft push checkbox-plano*.snap --release edge

now crashes with: http://pastebin.ubuntu.com/25132982/
The error handling itself has been reported here: https://bugs.launchpad.net/snapcraft/+bug/1705684

But to get back our daily builds I had to supply the X-Ubuntu-Store header in two places to be 100% sure to get a successful upload, in snap_push_precheck() and snap_push_metadata(). I do think it will be required in all SCAClient methods.

Here is a quick conversion of the pastebin from Natalia in to the aforementioned --store-id option to the push command:

Yes, but during the sprint with other snap store folks we decided that we wanted to redo how branded stores work in the backend and hold off client side changes.

1 Like

Could you expand on that @sergiusens please? What changes would be done to the brand store backend?

The exact length of changes are out of my scope but @cprov and @noise should be able to provide more feedback on this.

@sergiusens The store API now support that the store id is optionally sent while registering a name. This means that the call to /register-name/ can now send data like this:

{'snap_name': <value>, 'series': <value, optional, defaults to 16>, 'store': <store id, optional, defaults to main store>}

In a future iteration we will provide an API (or extend an existing endpoint) to list the stores a user can access.