'sign-build' implementation.

[cprov]

Supporting snap-build assertion generation and pushing to the Store.

Implements snapcraft sign-build <snap> as a discreet command for generating, signing and optionally pushing snap-build assertions to the store.

Next stage, when snap-build start to be required/checked on Store and snapd side, we will extend push & release commands to take this in consideration as well.

Supersedes #795 since Caio on leave this week.

https://bugs.launchpad.net/snapcraft/+bug/1628679

[sergiusens]

Looks generally good, just two questions aside from the one inline:

• Do you know when is snapd 2.15 landing? Or what is your ETA for this?
• Is there a way out after uploading the first build asserted snap?

[sergiusens]

and what should I do?

[sergiusens]

For your convenience:

snapcraft/_store.py:207:59: F821 undefined name 'assertion'
snapcraft/_store.py:208:15: F821 undefined name 'snapcraft'
snapcraft/main.py:307:80: E501 line too long (86 > 79 characters)
snapcraft/storeapi/__init__.py:22:1: F401 'subprocess' imported but unused
snapcraft/tests/test_commands_sign_build.py:22:1: F401 'tempfile' imported but unused
snapcraft/tests/test_commands_sign_build.py:220:5: E303 too many blank lines (2)
snapcraft/tests/store/test_store_client.py:168:1: E302 expected 2 blank lines, found 1
integration_tests/test_store_sign_build.py:29:1: E302 expected 2 blank lines, found 1
integration_tests/test_store_sign_build.py:79:80: E501 line too long (80 > 79 characters)

[sergiusens]

the integration tests are also failing

[cprov]

@sergiusens, thanks for the review.

I will get a find out a realistic ETA for snapd 2.15 (EOW probably, still in -proposed).

The loose/silly error message was removed and I will figure out a proper way to cleanup '-build' every time a blob is snap-ed (snapcraft snap). Lint issues fixed, and the integration tests failed because 2.15 is missing.

[cprov]

@sergiusens, the given ETA for snapd 2.15 is EOW (30th), so I guess it's not wise to land this PR until then, when we can get proper integrations tests passing.

Regarding your question about a "way out after uploading the first build assertion", the primary-key for a snap-build is the SHA3-384 digest of the snap, i.e. when rebuilt in any shape or form the new snap will not be tied to the previous snap-build anymore. Does it address your concerns ?

[sergiusens]

@cprov Oh, as of way out I meant if I push a snap with a build assertion, would the next snap I push require an assertion as well? If so, are the possible push errors sorted?

[cprov]

@sergiusens snap-build is orthogonal to pushing uploads, they are completely separated actions. You can push snap-builds to snap revisions already published as well as just before uploading them.

Same goes for 'release' while Store and snapd don't enforce matching snap-build assertions.

We will start requiring snap-build for releasing snaps to stables channel, then 'push --release' and 'release' commands will be extended to deal with a 'needs-signature' error scenario returned from the store, which will probably trigger an inline 'sign-build' action then re-submit.

Does it sound plausible ?

[sergiusens]

El 27/09/16 a las 13:59, Celso Providelo escribió:

@sergiusens https://github.com/sergiusens snap-build is orthogonal
to pushing uploads, they are completely separated actions. You can
push snap-builds to snap revisions already published as well as just
before uploading them.

Same goes for 'release' while Store and snapd don't enforce matching
snap-build assertions.

We will start requiring snap-build for releasing snaps to stables
channel, then 'push --release' and 'release' commands will be extended
to deal with a 'needs-signature' error scenario returned from the
store, which will probably trigger an inline 'sign-build' action then
re-submit.

Does it sound plausible ?

This makes perfect sense. I just needed to know someone was thinking
about this :-)

[sergiusens]

ok to test

[sergiusens]

What information? How can I solve this? Where to?

tsk tsk :-)