---
title: 'Snapcraft tricks: Improve release flexibility with pull and build overrides'
description: 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 al […]
url: https://canonical.com/blog/snapcraft-tricks-improve-release-flexibility-with-pull-and-build-overrides?format=md
---

1. [Blog](https://canonical.com/blog)
2. Article

---

[Igor Ljubuncic](https://canonical.com/blog/author/igorljubuncic "More about Igor Ljubuncic")

19 March 2020

# Snapcraft tricks: Improve release flexibility with pull and build overrides

[architecture](https://canonical.com/blog/tag/architecture)
[build](https://canonical.com/blog/tag/build)
[override-build](https://canonical.com/blog/tag/override-build)
[override-pull](https://canonical.com/blog/tag/override-pull)
[platform](https://canonical.com/blog/tag/platform)
[pull](https://canonical.com/blog/tag/pull)
[scriptlets](https://canonical.com/blog/tag/scriptlets)
[snapcraft](https://canonical.com/blog/tag/snapcraft)
[snapcraft.io](https://canonical.com/blog/tag/snapcraft-io)
[yaml](https://canonical.com/blog/tag/yaml)

---

Share the article

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](https://snapcraft.io/blog/kata-containers-a-form-of-art), 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](https://forum.snapcraft.io/) for a discussion.

Photo by [Macau Photo Agency](https://unsplash.com/@macauphotoagency?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).

[Get in touch

Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form)

## Sign up for our newsletter

Get the latest Canonical news and updates in your inbox.

Work email:

\*I agree to receive information about Canonical's
products and services.

By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy).

Sign up

## Share on

---

## Related posts

[### We wish you RISC-V holidays!](https://canonical.com/blog/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 themselves in the...

[Igor Ljubuncic](https://canonical.com/blog/author/igorljubuncic)

21 December 2023

[### Snapcraft 8.0 and the respectable end of core18](https://canonical.com/blog/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 peace! If you...

[Igor Ljubuncic](https://canonical.com/blog/author/igorljubuncic)

16 June 2023

[### TurtleBot3 OpenCR firmware update from a snap](https://canonical.com/blog/turtlebot3-opencr-firmware-update-from-a-snap)

The TurtleBot3 robot is a standard platform robot in the ROS community, and it’s a reference that Canonical knows well, since we’ve used it in our tutorials. As a matter of...

[gbeuzeboc](https://canonical.com/blog/author/gbeuzeboc)

25 September 2024

[### Creating Snaps on Ubuntu Touch](https://canonical.com/blog/creating-snaps-on-ubuntu-touch)

This article was written in collaboration with Alfred E. Neumayer of the UBports Project. Tablets, phones and current technology’s capabilities are phenomenal. Who would have...

[Aaron Prisk](https://canonical.com/blog/author/aaronprisk)

3 April 2024
