Snapcraft tricks: Improve release flexibility with pull and build overrides

by Igor Ljubuncic on 19 March 2020

Sometimes, software projects are simple – one architecture, one version, one release. But often, they can be complex, targeting multiple platforms, and with different versions at that. If you are packaging your apps as snaps, you might wonder about the optimal way to accommodate a multi-dimensional release matrix.

One yaml to rule them all

We encountered this during our 2018 November Snapcraft sprint, while working with the Kata containers team. They had a somewhat unique build process, where they would use multiple snapcraft.yaml files, each targeting a different version-architecture pair.

The way around this problem is to use a single snapcraft.yaml, with override-pull and override-build scriptlets used to resolve the pairing logic. Normally, snapcraft uses a single pull and build declaration for any specified part. However, developers have the flexibility to override the defaults, and create their own pull and build steps (as shell scripts).

Specifically, the Kata containers project required a different version of Golang for different platform architectures. This is the section of the snapcraft.yaml that satisfies this requirement:

parts:
  go:
    override-pull:
      git clone https://github.com/golang/go .
      case "$(arch)" in
        "x86_64")
          git checkout go1.11.2
        ;;
        "ppc64le")
        git checkout go1.10.1
        ;;
        "aarch64")
        git checkout go1.10.5
        ;;
        *)
        git checkout go1.11
        ;;
    esac

We can see how this applies to the build step, too. The Kata containers project features an unusual case where the kernel is bundled into the snap – however, this is expected for hypervisor technology. Similar to the pull step, the kernel configuration differs, and another case statement satisfies this requirement in much the same manner, except the override is for the build rather than the pull step. With the Golang part, the project needed different branches. The kernel source is identical, but the config files are platform-specific.

kernel:
  source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz
  source-type: tar
  plugin: kernel
  override-build: |
    case "$(arch)" in
      "x86_64")
      config=x86_64_kata_kvm_4.14.x
      ;;
      "ppc64le")
      config=powerpc_kata_kvm_4.14.x
      ;;
      "aarch64")
      config=arm64_kata_kvm_4.14.x
      ;;
    esac
    cp ${SNAPCRAFT_STAGE}/kernel/configs/${config} .config
    make -s oldconfig EXTRAVERSION=".container" > /dev/null
    make -j $(nproc) EXTRAVERSION=".container

Generic use case

This functionality can be extended to any project requirement where a developer would require either two different sources for different versions of the software, or different configurations for an identical source. Overall, it can simplify the release process, as there is no need to maintain multiple snapcraft.yaml files.

override-pull: |
  case “$variable” in
    “a”)
    something
    ;;
    “b”)
    something else
    ;;
  esac
override-build: |
  case “$variable” in
    “a”)
    something
    ;;
    “b”)
    something else
    ;;
  esac

Lastly, the override-pull and override-build clauses can also include the standard snapcraft pull and build scriptlets. For instance, you may not require multiple sources, but you might need to alter specific files or folders once they are downloaded, or edit certain components before the build step. A very rudimentary example would look like:

override-pull: |
      snapcraftctl pull
      ln -sf ../file ../../file

Summary

The pull and build override scriptlets offer snap developers a lot of freedom in how they construct their projects. There is often no need to maintain a complex release process, and it is possible to make the necessary adjustments through a single snapcraft.yaml file. The only practical limitation is the software itself, and your ability to tinker with shell scripts.

We hope you enjoyed this article, and if you have any feedback or suggestions, please join our forum for a discussion.

Photo by Macau Photo Agency on Unsplash.

Newsletter Signup

Related posts

Snapcraft:多应用客户端-服务端snap开发教程

在过去几个月我们发布了一些如何使用Rust,Java,C/C++和其他语言来开发snap桌面应用的文章。在这些从入门到精通的教程中,我们以一个代表性的snapcraft.yaml文件来介绍开发构建snap所需的具体细节。 今天,我们希望脱离这一过程,而将重点放在服务器端。我们将为你提供一个包含两个有趣组件的snapcraft.yaml的概述:a)它将拥有多个应用程序; 通常,snap包含一个应用程序。b)它具有简单的后台服务,其他应用程序可以连接到该服务。 我们一起来看一下。 Snapcraft yaml 以下是snapcraft.yaml文件的内容: apps: borg: command: bin/borg daemon: simple restart-conditi […]

Learn snapcraft by example – multi-app client-server snap

Over the past few months, we published a number of articles showing how to snap desktop applications written in different languages – Rust, Java, C/C++, and others. In each one of these zero-to-hero guides, we went through a representative snapcraft.yaml file and highlighted the specific bits and pieces developers need to successfully bui […]

Safely Backup Google Photos

With a smart phones in their pocket, most people don’t bother carrying a traditional camera anymore. For most, the single, double or even triple cameras on modern phones are great for making memories. Many Android and some iOS users have chosen to store their photos in the free or paid Google Photos service. In the […]