Your submission was sent successfully! Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

Snapcraft tricks: Improve release flexibility with pull and build overrides

This article is more than 4 years old.


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.

Ubuntu desktop

Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.

Newsletter signup

Get the latest Ubuntu news and updates in your inbox.

By submitting this form, I confirm that I have read and agree to Canonical's Privacy Policy.

Related posts

We wish you RISC-V holidays!

There are three types of computer users: the end user, the system administrator, and the involuntary system administrator. As it happens, everyone has found...

Snapcraft 8.0 and the respectable end of core18

‘E’s not pinin’! ‘E’s passed on! This base is no more! He has ceased to be! ‘E’s expired and gone to meet ‘is maker! ‘E’s a stiff! Bereft of life, ‘e rests in...

Craft team welcomes you to another episode of its adventures

Welcome to the second article in the Craft team saga. Previously, on Craft Team, we gave you a brief introduction into the team’s function, we announced our...