Better support for other CI systems

#1

Right now Snapcraft has the enable-ci command that currently integrates with Travis via the Travis gem. It fetches an attenuated macaroon, encrypts it using the Travis gem (which also saves the password into the Travis environment for the project in question), and modifies the .travis.yml file accordingly.

However, even that integration doesn’t work for all cases (e.g. when the snapcraft.yaml and .travis.yml are not next to each other), and we’re now looking to add support for other CI systems, and are finding that others do not work the same way as Travis. For example, Circle CI has no similar CLI tool. In an effort to make integrating snaps into a generic CI simpler, we need to extract some of that functionality into commands. Specifically, the ability to fetch and utilize an attenuated macaroon.

I propose this CLI change:

  • Add a get-token [--packages <packages>] [--channels <channels>] [--acls <acls>] FILE command that creates a file containing the macaroon attenuated as requested.
  • Add a --token option to the login command to login using the generated token file instead of username/password.

This simple change will unlock a lot of capabilities in any CI, and make future CI integrations much smoother.

Week 48 of 2017 in snapcraft
#2

Get token is a bit different from the language we are using already, which iirc would make the command be snapcraft get-macaroon

Are acls going to be blindly passed to the store or added to the schema locally?

#3

The underlying idea sounds very nice.

It would be good to have a command name that gives a better hint that this data is very sensitive, though, and people can do things with it even after it leaves the local machine.

We probably don’t even need to call out the fact that this is a macaroon, since the vast majority of people don’t know and don’t care about the internal details of this string.

Perhaps something like export-login and login --with=<string>?

#4

I figure the store validates them, so my plan was to just pass them through. If we both validate them, it’s an opportunity to get out of sync without much gain as far as I can see. I’ll do some testing though; if they aren’t validated, I’ll add a whitelist.

My thoughts exactly, although I like the idea of just reusing “login” instead of trying to shoehorn “token” or something else people understand into working for us. +1 to export-login and login --with.

#5

+1 on export-login

#6

+1 to --export-login and explicit login --with

#7

Thanks @cprov, this one’s inspired by you. I’m glad you saw this, should make our meeting even faster.

Pushing and Releasing Snaps with CI
#8

PR implementing this is up:

#9

@kyrofa as you are aware, you’ve just released support for more granular permissions in the Store. Now developers can export-login with much tighter restrictions like: package_push, package_release, package_update or package_metrics.

See more details in https://dashboard.snapcraft.io/docs/api/macaroon.html#post--dev-api-acl-

It works just fine in existing snapcraft revisions:

$ snapcraft export-login --snaps surl --acls package_push --expires '2018-04-01 00:00:00' push_surl_login
...

Login successfully exported to 'push_surl_login'. This file can now be used with
'snapcraft login --with push_surl_login' to log in to this account with no password
and have these capabilities:

snaps:       ['surl']
channels:    No restriction
permissions: ['package_push']
expires:     2018-04-01T00:00:00

This exported login is not encrypted. Do not commit it to version control!

But soon snapcraft itself and travis integration (enable-ci travis) will be using tuned macaroons too.

ISV questions about signing a snap
#10

We should update https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-circle-ci#4 with the new best practices when snapcraft 2.40 is out