snippy snappy

[Scarlett Clark]

Nice work :) I will get started asap. Monday is a holiday though.
Cheers,
Scarlett


On Fri, Sep 1, 2017 at 5:02 AM, Harald Sitter <sitter at kde.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/neon/attachments/20170901/52d8a296/attachment.html>