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
job-updater generates jobs. the jobs are on the build view , 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  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
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 .
To get started grab the snapcraft.yaml, desktop file and icon and put
them in the packaging repo. kblocks is a good example . 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
Also note that because of problem 10  you'll have a hard time
testing this unless you first push it to the edge channel and install
it from the store.
- 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
Go forth and snapeth the world.
More information about the neon