Add the packaging metadata to build the syncthing snap

[elopio]

This is a package for the secure installation of apps that works in most Linux distributions.
Landing it upstream will enable builds for adventurous users.

[elopio]

You can find more information about snapcraft here: http://snapcraft.io/

If we upload the snap to the ubuntu store we will get a great way to deliver the software, and get transactional automatic updates. I've been testing the snap [1] and it seems to me good enough to publish in the edge channel, which will make it really easy to do crowd-testing before the stable release. Also I would love to have syncthing in my rpi, dragonboard and beaglebone, that are doing different functions around my house :)

If you have any doubts or comments, please let me know.

[1] https://gist.github.com/elopio/bd8647ae25407804bf3936157302dc6b

[elopio]

Oh, and I also worked a little on snaps for syncthing-cli ( elopio/syncthing-cli@11cef3a ) and syncthing-gtk ( elopio/syncthing-gtk@f38afac )

I need to test the CLI a little more, and fix the gtk client because it's crashing.

[calmh]

Thanks, this is interesting. How do we best build and test the results?

[calmh]

Is this plugin a strict requirement to be able to build the snap? Must it be a Python plugin or could it be integrated into our regular build process? If it must exist as is, is the "parts" path also a strict requirement?

[elopio]

It is now. You are using a non-standard build step that doesn't fit with the default go plugin in snapcraft. It most be python if you want to use snapcraft to direct the build, but there are alternatives.
For example, we could use make, cmake or some other build tool supported by snapcraft to do some of the things that this plugin is doing, and then snapcraft can use the make or cmake plugin. Also there are some discussions in progress to make it better, like adding hooks to the base plugins so we can extend or overwrite just parts of them and make the custom plugins smaller, or like having a generic plugin that just calls shell commands to direct the build.
For now, the custom plugin must exist in parts/plugins. After trying to snap a few projects, I'm not so happy with that location. I'm thinking about something in .snapcraft, or customizable, but haven't reported a bug about that yet.

Thanks for your questions @calmh. That's precisely the reason I'm looking for upstreams, to get more feedback and add new items to the roadmap. So if you have suggestions or there are things you hate, please, let us know.

[calmh]

Hardcoding maxprocs to 1 here is unusual. Why?

[calmh]

Likewise -verbose is not usually the right thing to default to.

[popey]

I think Leo inherited those two options from a prototype of the syncthing snapcraft.yaml I previously was working on. I was using them for debugging my broken build, so agreed, they can go.

[elopio]

Yes, indeed. I've removed them and I'm testing the resulting snap.
btw, thanks to @popey for all the work getting this started.

[elopio]

I also removed the -home and -logfile so it takes the default. Default $HOME when the snap command runs should be in /home/$USER/snaps/syncthing/$revision/, the snap user dir.

[calmh]

If $revision there is our version number (i.e. 0.14.7), it is probably not appropriate to get a new home dir on upgrade as that would wipe out the existing config and database. But I assume there is some common best practice thinking around this for snaps in general?

[kyrofa]

@calmh it won't be wiped out. Part of the upgrade process is to copy the previous revision's data into the new location. This gives the snap the opportunity to mutate the data in some way for the upgrade and, if it fails for some reason, to rollback to the previous revision (and its un-mutated data).

However, it's my understanding that using $SNAP_USER_DATA as the --home will also set that directory up as the default sync directory, which probably isn't what you want (due to the fact that the directory is copied upon upgrade). Ideally you could store the configuration within $SNAP_USER_DATA, but have raw unversioned data in $SNAP_USER_COMMON, which doesn't get copied for upgrades. See Where can Ubuntu snaps write data? for more information on these directories.

[elopio]

The steps to build and test are in my gist: https://gist.github.com/elopio/bd8647ae25407804bf3936157302dc6b
Once the yaml is in the repository tree, there are some interesting things we could do to test the build and automate the delivery, like using travis and docker to build the snap, and push it to the edge channel on the store for changes in the master branch. Or we could push every change on master to launchpad, and configure launchpad to build the snap for all the supported architectures and push to the store.

[calmh]

For what it's worth, I'd much prefer something like a top layer Makefile that is a thin wrapper around build.go. That might even be a useful interface for humans, as make is shorter than go run build.go and the only reason for the existence of build.sh currently is that it's more convenient to type. :)

[calmh]

@st-jenkins add to whitelist

[elopio]

@calmh I hear you. So here's an alternate approach.
We use build.go to call snapcraft. This build file is a little complex, so please kindly let me know if I totally misunderstood it :) I have updated the steps to test in my gist.

I think this way it would be really easy to build all the snaps for all the architectures. I'm almost sure we would just have to add the architectures entry to the yaml, and generate the right binary; but I would prefer to do the other ones after we test this a little more.

[calmh]

So this works and is clean enough. However, it's always built as version master. From some googling, it appears this value must be hardcoded in the snapcraft.yaml file. Should we instead have a snapcraft.yaml.template that the build script reads, replaces version tag in, and then creates a snapcraft.yaml from?

What's the process for a user to install the created snap? I assume it must be signed somehow and pushed to some repository? Do we set up a snap repository of our own or use some central one?

[elopio]

That is a good point. Please review my new commit.
In case you are interested in the details, we are discussing here [1] how to make this without templates. We are probably going to add a snapcraft --version flag that will overwrite the version value in the yaml.

About the repository, we have a central ubuntu store, and obviously I will recommend you to use that one. You need to register the snap name, and then push and release: http://snapcraft.io/docs/build-snaps/publish
The push and release process can be automated with travis, launchpad or something else.

[1] https://lists.ubuntu.com/archives/snapcraft/2016-September/thread.html#907

[calmh]

@st-jenkins retest this please

[calmh]

@st-review merge it

build: Add build method for snapcraft

[st-review]

👌 Merged as 31d9750. Thanks, @elopio!