Skip to main content

Your submission was sent successfully! Close

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

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

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.

Related posts


Igor Ljubuncic
21 December 2023

We wish you RISC-V holidays!

HPC Article

There are three types of computer users: the end user, the system administrator, and the involuntary system administrator. As it happens, everyone has found themselves in the last group at some point or another; you sit down to perform a task relevant to your needs or duties, but suddenly the machine does not work as ...


Igor Ljubuncic
16 June 2023

Snapcraft 8.0 and the respectable end of core18

Ubuntu Article

‘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 peace! If you hadn’t nailed ‘im to the perch ‘e’d be pushing up the daisies! ‘Is software processes are now ‘istory! ‘E’s ...


Igor Ljubuncic
21 March 2023

Craft team welcomes you to another episode of its adventures

Ubuntu Article

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 desire to share the ins and outs of our day-to-day work with the community, and gave you an overview of roughly two weeks of coding and fun. Today, ...