Run scripts during snapcraft builds with “scriptlets”

by David Callé on 2 February 2017

Please note: this blog post is over 5 years old and is out of date. Scriptlets have been superseded by Overrides.

If you have snapped an application, or tried to snap an application, you know that Snapcraft heavily depends on built-in plugins for specific build systems and that it provides a large array of choices to do so. You can snap ROS apps, Python 2 and 3 apps, Go apps, Rust apps, Java apps, Linux kernels and many more, by simply declaring the right plugin name.

What if your app depends on multiple build systems? Or uses a custom build script, or maybe you want to run make test as part of a snapcraft build? Until recently, you had to write a custom plugin and ship it along your snapcraft.yaml, which was working fine but took time to achieve and made you ship an extra directory just for it. With Snapcraft “scriptlets”, this is over and the path to snapping is now much faster.


Scriptlets are shell scripts, sourced directly from your snapcraft.yaml, that change the behaviour of a plugin. They can be triggered before the “build” step to run commands on your source code before building it, instead of it, to completely override the building behaviour and after: to move build artefacts around, change a config file or anything that you would need to happen after the build.

How to use them

Scriptlets are declared using specific keywords in your snapcraft part:

  • prepare: for commands that need to happen before the build step of a plugin
  • build: to override a plugin’s build step
  • install: for commands that need to happen after the build step

Have a look at the documentation for more details, or see the following examples to get started: a demo of the prepare scriptlet and a real world use case with the MySQL snap.

Real world use case: MySQL

Let’s see how the MySQL snap uses the prepare: keyword to pull deb packages from their server, unpack and load them into the project directory during a snapcraft build.


If we look at the parts: section of the snapcraft.yaml we can see a mysql-server part, that dumps a pre-built MySQL into the snap.

    prepare: ./
    build-packages: [libaio-dev, libmecab-dev, libnuma-dev, libncurses5-dev, zlib1g-dev]
    plugin: dump
    source: ./
      staging-files/usr: usr/
      - usr/lib/mysql/plugin/
      - usr/lib/mysql/plugin/
      - usr/lib/mysql/plugin/
      - usr/bin/my_print_defaults
      - usr/bin/mysqldump
      - usr/bin/mysql_tzinfo_to_sql
      - usr/bin/mysql_upgrade
      - usr/share/mysql/*

The script called at the prepare stage is

SNAPTMP=$(mktemp -d)
tar -xvf "${FILENAME}" 
ar x mysql-community-client_${MYSQL_VERSION_FULL}_amd64.deb
tar -xvf data.tar.xz
rm data.tar.xz
ar x mysql-community-server_${MYSQL_VERSION_FULL}_amd64.deb
tar -xvf data.tar.xz
mkdir staging-files
mv usr staging-files/
rm -rf ${SNAPDIR}/staging-files
mv staging-files ${SNAPDIR}

It uses wget to download mysql debian packages, unpack them and copy their content into the current directory.

Once this prepare script is run, the dump plugin proceeds as usual: taking content from the source and including it in the final snap.

Without this scriptlet, there would have been a need for a custom plugin or several other parts that would have increased the complexity of the snapcraft.yaml.

More examples

You will find usage snippets on the scriptlets page at and in the snapcraft test suite:

Newsletter Signup

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 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 […]

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

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 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, […]