snippy snappy

Harald Sitter sitter at kde.org
Fri Sep 1 12:02:44 UTC 2017


Final pieces are in place and we can build snapcraft.yamls from our
unstable branch now without having an opaque auto generation step in
between.

job-updater generates jobs. the jobs are on the build view [1], the
old view is now called 'snap (gen)' which is still auto generating
release snaps from existing data.

To generate new data you can use my autogen repo [2] to generate a
simplified yaml file to get started

```
echo 'kblocks' > appname; SIMPLE=1 ruby generate.rb
```

this dumps a snapcraft.yaml which looks a lot like the existing
autogenerated ones but with 2 core differences:

- it doesn't include a massive exclusion list to not create overlap
with the kf5 snap
- it doesn't include the boilerplate parts for -dev and -env but still
references them

The former is injected by new build time tooling for CI only.

The latter is now solved using the snapcraft native remote parts tech.
Since I am currently still playing around with this we use a separate
remote parts definition URI from upstream [3].

To get started grab the snapcraft.yaml, desktop file and icon and put
them in the packaging repo. kblocks is a good example [4]. Run
job-updater. You should get a new job. Run the job. Barring mistakes,
this should push a master build into the edge channel.

This snapcraft.yaml will have a release tarball listed as source.
Don't worry. The build time tooling automatically adjusts the file to
be a git build and also adjusts the version to reflect this.

You can technically build a snap on your machine in a container as
well (needs unstable repo), though I am not sure why you would. You
will need to change your snapcraft's parts uri though

```
export SNAPCRAFT_PARTS_URI=http://metadata.neon.kde.org/snap/parts.yaml
snapcraft update
snapcraft
```

Also note that because of problem 10 [5] you'll have a hard time
testing this unless you first push it to the edge channel and install
it from the store.

Limitations:
- currently the jobs are only created for unstable
- only for applications component
- the built snaps will get landed in the edge channel and nowhere else
(which is intentional for unstable mind you)
- while all applications use master as development HEAD the tooling
hardcodes this instead of following our existing override tech, so not
really a problem right now but will be eventually
- the repos do not get auto-polled for changes (which I think will
need solving on the git.kde.org as with snapcrafting we don't really
need a daily poll anymore as everything is isolated and
non-interfering)

Go forth and snapeth the world.

[1] https://build.neon.kde.org/view/snap%20(build)/
[2] https://github.com/apachelogger/kf5-snap-app
[3] http://metadata.neon.kde.org/snap/parts.yaml
[4] https://packaging.neon.kde.org/applications/kblocks.git/tree/?h=Neon/unstable
[5] https://community.kde.org/Neon/Snap#Problems


More information about the neon mailing list