Release Edge 1 - Bare Minimum

Currently the code is capable of providing some basic functionality for a snap store, like listing snaps, installing them, etc. As I’ve previously mentioned I’ve even built Core images pointed at that store.

There are a ton of facets to work on with a project like this obviously (ton is an understatement actually).

And while just “working” on it is a lot of fun I do actually want to make plans, release and make a usable project.

So- it’s time to start with planning the first “release”. There will be several main components/services (each one in turn out-lined afterwards):

  • Login
  • Dashboard
  • Store
  • Kebe
  • Support
  • Tools

This is also in the context of a single, global store. Other store support will have to come later.


Login

Login will support authenticating that a user exists through an OIDC provider (I’ll most likely being using Keycloak for this role during development). It will discharge a third-party caveat when requested.

All new users, management, etc. will be the responsibility of the OIDC provider at this point.

Dashboard

Dashboard should support as much as possible to make the release meaningful. Definitely planned:

  • Register a snap name
  • Push a snap build to the store
  • Basic account / key management

Store

Store should support as much as possible to make the release meaningful. Definitely planned:

  • Get snaps
  • Search snaps

Kebe

Kebe will have backend and admin endpoints that are not provided elsewhere. The hope is to have an OpenAPI or similar specification to cover these.

Support

Helm chart for basic deployment and development. It will be non-production and will likely not have proper Ingress support, SSL, etc. until later.

** Tools **

The goal is to have the current functionality supported using the existing tools with simple exported environment variables to overload the URLS.

Snapd is of course another matter as it needs a patch for adding another “root” account and key to allow another party to attest to assertions. At the moment I do not believe there is an alternative.

I would like to have an “all-in-one” box for this purpose; capable of deploying and initializing the store from scratch (or with existing keys), patching snapd with the store generated assertions and then building both the debian package and snap. This could potentially be done with Vagrant or just a single Taskfile.

Additionally leading up to that point and certainly afterwards all development will be driven by PRs, even my own.

This has been removed until such time as it is necessary.

Collected some more details for the plan:

	// TODO: implement /dev/api/account/account-key for `snapcraft register-key`
	// TODO: implement /api/v2/snaps/<snap-name>/releases for `snapcraft list-revisions <snap-name>`
	// TODO: implement /api/v2/snaps/<snap-name>/channel-map for `snapcraft list-tracks <snap-name>`
	// TODO: implement /dev/api/snap-release/ for `snapcraft release <snap-name> <revision> <channels>`
	// TODO: implement /dev/api/snap-push/ for `snapcraft upload <snap-name>`

I think some functionality will be needed here longer term because things like creating tracks does not exist in a public facing tool (afaik).

I’m not sure whether making it a requirement of Release Edge 1 is necessary. If by default the normal ones are created either when the snap name is registered or at some point (first snap revision uploaded, etc) then it may not be a hard requirement.

We can easily create latest/stable, latest/candidate, latest/beta and latest/edge automatically.