Shulou(Shulou.com)06/01 Report--

This article mainly introduces how linux uses Snapcraft to build, test and publish Snap software packages. The article is very detailed and has certain reference value. Interested friends must read it!

Snapcraft is a package management system that is fighting for its place in Linux, reimagining the way you distribute software. This new set of cross-distro tools can be used to help you build and distribute snap packages. Next we'll talk about how to use Circle CI 2.0 to speed up this process and some of the problems you might encounter along the way.

What is the snap package? What is Snapcraft?

Snaps are software packages for Linux distributions that were designed with lessons learned from distributing software on mobile platforms like Android and IoT devices. The name snapcraft encompasses snap and the command-line tools used to build them, this website snapcraft.io, and almost the entire ecosystem built on top of these technologies.

Snap packages are designed to isolate and encapsulate entire applications. These concepts enable Snapcraft's goal of improving software security, stability, and portability, where portability allows a single snap package to be installed not only in multiple versions of Ubuntu, but also in distributions such as Debian, Fedora, and Arch. Snapcraft describes it as follows:

Package any application for every Linux desktop, server, cloud or device and deliver updates directly.

Build snap package on CircleCI 2.0

Using CircleCI 2.0 syntax to construct snaps on CircleCI is essentially the same as on the local machine. In this article, we'll look at an example configuration file. If you're new to CircleCI or want to learn more about getting started with 2.0, you can start here.

basic configuration

version: 2 jobs: build: machine: true working_directory: ~/project steps: - checkout - run: command: | sudo apt update && sudo apt install -y snapd sudo snap install snapcraft --edge --classic /snap/bin/snapcraft

This example uses the machine executor to install the snapd executable for managing snap runs and the snapcraft tool for making snap.

Since the build process requires a relatively new kernel, we use machine executors instead of docker executors. Linux v4.4 is sufficient for our needs.

User-space dependencies

The above example uses a machine executor, which is actually an Ubuntu 14.04 (Trusty) virtual machine with Linux v4.4 kernel. If the Trusty repository can satisfy your project/snap build dependencies, that's fine. If your build dependency requires another version, such as Ubuntu 16.04 (Xenial), we can still use Docker in the machine executor to build our snap package.

version: 2 jobs: build: machine: true working_directory: ~/project steps: - checkout - run: command: | sudo apt update && sudo apt install -y snapd docker run -v $(pwd):$(pwd) -t ubuntu:xenial sh -c "apt update -qq && apt install snapcraft -y && cd $(pwd) && snapcraft"

In this example, we again installed snapd in the machine executor's VM, but we decided to install snapcraft in the Docker container built from the Ubuntu Xenial image and use it to build our snap. This way, all apt packages available in Ubuntu 16.04 can be used while Snapcraft is running.

test

There is already a lot of content on our blogs, documentation, and the Internet on how to unit test software code. Search your language or framework and unit tests or CI to find a wealth of relevant information. Building the snap package on CircleCI, we end up with a.snap file, which means we can test it in addition to the code that created it.

workflow

Assuming we build a snap package as a webapp, we can test the suite to make sure snap installs and runs correctly, try installing it or use Selenium to test page loading, login, etc. But there is a problem here, because snap is designed to run on multiple Linux distributions, which requires our test suite to work properly on distributions such as Ubuntu 16.04, Fedora 25 and Debian 9. This problem can be effectively solved through the CircleCI 2.0 workflow.

Workflow was added in the recent beta release of Circle CI 2.0 and allows us to run discrete tasks through specific logical flows. This way, after building snap with a single task, we can start running snap distribution test tasks in parallel, each for a different distribution of Docker images (or other executors available in the future).

Here's a simple example:

workflows: version: 2 build-test-and-deploy: jobs: - build - acceptance_test_xenial: requires: - build - acceptance_test_fedora_25: requires: - build - acceptance_test_arch: requires: - build - publish: requires: - acceptance_test_xenial - acceptance_test_fedora_25 - acceptance_test_arch

In this example snap was built first and acceptance tests were run on four different distributions. If all distributions pass the test, we can run the release job to complete the remaining snap tasks before pushing it to the snap store.

Keep the.snap pack.

To test the.snap package we used in our workflow example, we needed a way to persist snap at build time. Here I will offer two ways:

artifact -We can save snaps as a CircleCI artifact while running the build task, and retrieve it in subsequent tasks. CircleCI workflows have their own way of handling shared artifacts, which can be found here.

Snap Store Channels--When publishing snap packages to the snap store, there are multiple channels we can choose from. It has become common practice to publish the main branch of snap to the edge channel for internal or user testing. We can do this in the build task, and then the next task can install the built snap package from the edge channel.

*** This method is faster, and it also allows acceptance testing of snaps before they are uploaded to the snap store for use by users or even test users. The benefit of the second method is that we can install snap from the snap store, which is also one of the test items during CI runs.

Snap store authentication

The snapcraft-config-generator.py script generates store certificates and saves them to.snapcraft/snapcraft.cfg (note: always check them before running public scripts). If you don't feel safe storing the file in plain text in your repository, you can encode the file in base64 and store it as a private environment variable, or you can encrypt the file and store the key in a private environment variable.

Here's an example of putting the store certificate in an encrypted file and using it in the deploy link to publish snap to snap store.

- deploy: name: Push to Snap Store command: | openssl aes-256-cbc -d -in .snapcraft/snapcraft.encrypted -out .snapcraft/snapcraft.cfg -k $KEY /snap/bin/snapcraft push *.snap

The workflow example is the same as before except that the deploy task runs only if the acceptance test task passes.

That's all for "How linux uses Snapcraft to build, test, and distribute Snap packages." Thanks for reading! Hope to share the content to help everyone, more relevant knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.