ubuntu-appstore-developers team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

On Tue, 25 Mar 2014 15:11:19 -0300, Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx> wrote:
> Hi all,
> 
> Alexander raised an interesting requirement on IRC, that I'd like to
> discuss a bit to figure out how to best implement it.
> Creating an image today is tied to being able to upload core apps to
> the store first, which creates a bit of a chicken-and-egg story for
> continuous integration. Lets fix this.
> 
> Currently you can upload apps and not publish them directly. I think
> that's essentially "staging" them, what I believe we lack today is the
> ability to do some CI with unpublished apps.
> 
> I can see others also wanting to be able to stage and test their apps,
> before they become public.
> 
> So, what I understand we need to provide, as a minimum feature is:
> - A way to programatically upload and download apps, before they are
> published (or maybe even reviewed?)
> - A way to limit access to who can access these files for download
> - A way to programatically publish them once it passes all tests
> 
> A few questions as well:
> - Can we use the same credentials as the user that uploads them?
> - Do we need to also provide all the data in click index, or just the
> ability to download a file you know the name beforehand?
> - Anything else?

We (online services) discussed on IRC some of the changes that we would
have to make to support this.

So to sketch things out more fully:

  - A touch image includes certain core apps.
  - This image is built by searching the store for those particular apps
    and downloading the version that is found.
  - We want to be able to build an image using the same process that
    instead includes the unpublished version of an app instead. This
    will allow for testing that app, and will be required before the app
    is published.

Further notes:

  - We don't want the unpublished versions to be generally available.
  - This is a feature that external developers may want to use as well,
    such as having a beta channel for enthusiastic users/testers.

As you suggest this would be fairly easy to implement if we can use the
same credentials as the user that uploads the apps, and if we don't need
to download them via the index, as all the code is already present to be
able to support this.

If not, or to expand the idea to channels that external developers can
use, we would have to tackle the following things server-side:

  1) Indexing the unpublished apps.

  Currently click-package-index (c-p-i, search.apps.ubuntu.com) knows
  nothing about unpublished apps. We would have to change
  software-center-agent (s-c-a) to tell c-p-i about them, and index them
  appropriately. I assume this is straightforward.

  2) Authentication.

  We want to restrict access to the unpublished apps, so we need to
  authenticate requests for them. c-p-i currently requires no
  authentication. We would change it to accept oauth-signed requests and
  verify them. A verified oauth-signed request could then request
  including unpublished apps, but there would be no change for existing
  behaviour.

  3) ACLs for unpublished apps

  We would then need a way to allow a user access to particular
  unpublished apps. If we are just doing this for our internal use then
  this should be fairly easy, but if we want to open it up then there
  would be more work providing a good UI for this.

  4) Choosing which unpublished apps to include

  When a user does a search we need to decide what they will see if they
  have access to unpublished apps. We could return both versions, or
  just the newest version. If this is for internal use by the image
  builder then it doesn't really matter, but if it's for external use
  then it is important.

  Note that this scheme would also likely mean that a search for apps on
  a test image would return older versions than those that are
  installed. I don't know if this would be a problem for testing, or
  even if you would notice.

So we have a few questions to answer, and work to do across several
projects, but we would be able to adjust the effort involved by
restricting the scope to just solving the case for image testing, rather
than trying to provide a polished feature for external developers.

Thanks,

James