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?

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.

Source: https://github.com/mysql/mysql-snap/blob/5.7/snapcraft.yaml

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.

parts:
  mysql-server:
    prepare: ./stage_binaries.sh
    build-packages: [libaio-dev, libmecab-dev, libnuma-dev, libncurses5-dev, zlib1g-dev]
    plugin: dump
    source: ./
    organize:
      staging-files/usr: usr/
    snap:
      - usr/lib/mysql/plugin/mysql_no_login.so
      - usr/lib/mysql/plugin/innodb_engine.so
      - usr/lib/mysql/plugin/mypluglib.so
      <snip>
      - 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 stage_binaries.sh
(source: https://github.com/mysql/mysql-snap/blob/5.7/stage_binaries.sh)

SNAPDIR=$(pwd)
SNAPTMP=$(mktemp -d)
cd ${SNAPTMP}
MYSQL_VERSION_MAJOR=5.7
MYSQL_VERSION_FULL=5.7.17-1ubuntu16.04
FILENAME="mysql-server_${MYSQL_VERSION_FULL}_amd64.deb-bundle.tar"
wget "http://dev.mysql.com/get/Downloads/MySQL-{MYSQL_VERSION_MAJOR}/${FILENAME}"
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}
cd ${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 snapcraft.io and in the snapcraft test suite:

• Prepare
• Build
• Install