A new release

New in this release

Core

snapcraft promote

Promotion is introduced as a hidden command in this release to be able to release a set of revisions.
A build set is a set of snap revisions that meet a certain criteria, the most simple form of a build set is a set of revisions released to a channel.

When this command is used a warning will be displayed as the command syntax may change
Here's the feature on used to promote snapcraft from beta to candidate:

snapcraft promote --from-channel beta --to-channel candidate snapcraft
snapcraft promote does not have a stable CLI interface. Use with caution in scripts.
Build set information for 'beta'
Arch       Revision    Version
amd64          2947        3.5
arm64          2952        3.5
armhf          2951        3.5
i386           2949        3.5
ppc64el        2950        3.5
s390x          2948        3.5
Do you want to promote the current set to the 'candidate' channel? [y/N]: 

Execution time stamping

Improved build-aux support

---

The issues and features worked on for 3.5 can be seen on the 3.5 launchpad milestone which are reflected in the following change list:

Sergio Schvezov

• vcs: ignore .idea (#2558)
• ci: remove dependency on LXD from travis tests (#2557)
• cli: snapcraft promote (#2556) (LP: #1827513)
• manifest: expose snapcraft-started-at (#2559) (LP: #1806658)
• storeapi: allow promotion from branches
• tests: release and promote to grade devel channels
• tests: fix the status test
• tests: add ppc64el to the fake server info results

Claudio Matsuoka

• project: read local plugins from build-aux (#2551) (LP: #1827095)
• extensions: block direct use of private extensions (#2555)

Daniel Llewellyn

• meta: take ${SNAP} into account .desktop icon checks (#2541)

Minor improvements

Hello Snapcrafters! The Snapcraft team is pleased to announce that version 3.4.1 is out.
This is a minor point release to fix some outstanding issues.

New in this release

Core

LXD build environment

Removed warning about unused attributes from pylxd

Appstream

When using the appstream extractor in a part combined with the common-id keyword for an app entry, a warning will be raised when the common-id does not match any extracted appstream ID.

Environment

SNAPCRAFT_PROJECT_DIR is now exported as an environment variable, usable when doing override-<step>.

Plugins

rust

The plugin now works once more when using the nightly channel through the plugin's rust-channel parameter.

catkin

The catkin plugin has been updated to reflect some repository changes with regards to python and now uses the build environments compiler to execute the build instead of staging it into the parts building area through the plugin.

---

The issues and features worked on for 3.4.1 can be seen on the 3.4.1 launchpad milestone which are reflected in the following change list:

Sergio Schvezov

• tests: add a set_confinement helper
• tests: classic confinement spread tests for ant and maven (LP: #1805206)
• build providers: get rid of attribute warnings from pylxd (#2535)
• rust plugin: fix usage of rust-channel (#2538) (LP: #1825062)
• storeapi: move from details (v1) to info (v2) (#2550)

Tony Simpson

• project loader: add SNAPCRAFT_PROJECT_DIR environment variable (#2534) (LP: #1824417)

Kyle Fazzari

• tests: allow python2 as well as python for catkin spread tests (#2540)
• integration tests: use correct series in get_package_version (#2548)
• catkin plugin: use build-packages for compilers (#2545) (LP: #1827148)

Claudio Matsuoka

• extractors: fix typo in appstream icon unit test (#2543)
• meta: Validate common ID against appstream metadata (#2542) (LP: #1814902)

Say hello to snapcraft 3.4

New in this release

snapcraft snap

The snapcraft snap has now moved to using base: core, this unlocks snapcraft into using the snapcraft 3.0 features in its own snapcraft.yaml in order to build snapcraft from snapcraft (lots of snapcraft in that sentence!)

Core

New build provider support: LXD

You can now use LXD as a build provider, operations supported by the default mode (using multipass) are also supported with LXD, such as:

• --shell
• --shell-after
• --debug

To trigger use of LXD, the snapcraft lifecycle commands (pull, build, stage and prime, together with clean) need use the --use-lxd option.

This feature is introduced early to get feedback, but is not production ready unless it is a discardable CI environment. Early adopters may see future (with no automatic migration) changes to:

• storage setups
• default profiles
• use of LXD projects

snapcraft try

By default, when triggering builds in a clean environment, it is sometimes desirable to have the prime directory locally to be able to snap try prime. For this reason snapcraft try will run through the lifecycle all the way to prime(if not run before) and offer the prime directory locally.

While this version of snapcraft is not on stable, when combined with --use-lxd, one must pass SNAPCRAFT_BUILD_ENVIRONMENT_CHANNEL_SNAPCRAFT=latest/candidate to snapcraft. Support for snap injection for LXD will be worked on when snapd 2.38 is released.

Plugins

go

The go plugin now works more broadly when using classic confinement. This should avoid the necessity of specifying no-patchelf for parts failing to patch correctly.

catkin

The catkin plugin has been enhanced to support stage-snaps to satisfy dependencies, a detailed write up can be found on the snapcraft blog.

---

The issues and features worked on for 3.4 can be seen on the 3.4 launchpad milestone which are reflected in the following change list:

Sergio Schvezov

• build providers: modify the _run signature (#2511) (LP: #1821401)
• build providers: support for provider setup (#2515) (LP: #1821586)
• readme: add snap store badge (#2516)
• build providers: initial support for LXD (#2509) (LP: #1805221)
• cli: cleanup environment detection (#2521)
• build providers: add API for friendly instance type names (#2522)
• snap: set core as a base (#2520)
• ci: improve travis integration conditionals (#2523)
• cli: snapcraft try (#2524) (LP: #1805212)
• build providers: idempotent destroy for LXD (#2529)
• tests: add missing pylxd Build-Depends
• tests: restrict catking stage-snap tests arches

Claudio Matsuoka

• repo: handle deb package fetch error (#2513)
• project: ensure yaml load returns a dictionary (#2517)
• many: better handling of appstream icons (#2512) (LP: #1814898)
• go plugin, elf: use patchelf 0.10 and relink dynamic go binaries (#2519)
  (LP: #1805205)
• snap: use snapcraft's 0.10 patchelf branch (#2528)
• snap: revert to patchelf 0.9 with local patches (#2531)

adanhawth

• schema: add more detail wrt numeric version errors (#2506)

Kyle Fazzari

• catkin plugin: check stage-snaps for ROS dependencies (#2525)

Introducing snapcraft 3.3

New in this release

Core

base: core

In order to use the new features of snapcraft, introduced with 3.0, and still use 16.04 as a base, support for use of base: core has been added. This will trigger the same semantics as using the base keyword in snapcraft.

Alternate directory for snapcraft.yaml

build-aux/snap is now supported as an alternative directory for snapcraft.yaml and its assets (i.e.; hooks, gui, ...). To avoid confusions, snapcraft now display what directory it is picking for assets depending on where the snapcraft.yaml is found. It will only pick build-aux/snap for assets if the snapcraft.yaml is found in that path.

string validations

Snapcraft now produces a better error for when the type detected for the version string is not a string.

Plugins

python

A minor fix which should bring rebuilding capabilities to projects using the python plugin.
Long gone should be the days of seeing messages of the following construct:

You must give at least one requirement to install (maybe you meant "pip install …")

python and go

Expanded schema errors for users of the go and python, allowing for early discovery of non-valid uses of these plugins. Most importantly, this eliminates the cryptic error during build time when not using a combination of the source and <plugin-name>-packages keywords.

nodejs

Entries of type string are now supported in package.json for the bin keyword (previously, the plugin could only parse dictionary entries), this means that constructs from package.json of the form:

{
  "name": "unnamed",
  "version": "1.0",
  "description": "Using string bin entries.",
  "main": "index.js",
  "bin": "bin/index.js",
}

should be parse and interpreted correctly by snapcraft.

Store

Register against a specific store

Brand stores are a commercial feature of the Snap Store.

The following syntax is now allowed as part of the register command:

snapcraft register [--store <store>] <snap-name>

Which will allow users to register snaps for specific brand stores.

The issues and features worked on for 3.3 can be seen on the 3.3 launchpad milestone which are reflected in the following change list:

Sergio Schvezov

• many: support for "base: core" in snapcraft.yaml (#2499) (LP: #1819290)
• python plugin: graceful ret when no packages set (#2498) (LP: #1794216)
• many: support the use of build-aux/snap (#2496) (LP: #1805219)
• nodejs pluging: support for type str bin entries (#2501) (LP: #1817553)
• store: support registering to a specific store (#2479) (LP: #1820107)
• meta: fix management of snap/local (#2502)
• tests: improve login pexpect errors
• tests: correctly retry registers
• build providers: enhance provider errors (#2508) (LP: #1821217)
• build providers: improve handling in snap logic (#2507) (LP: #1820864)
• tests: filter per arch and fix snap build deps

Claudio Matsuoka

• sources: handle network request errors (#2494)
• store: handle invalid snap file errors (#2492)
• tests: fix multipass error handling spread test (#2491)
• plugins: improve python and go schema validation (#2473) (LP: #1806055)
• cli: disable raven if not running from package (#2503)

Facundo Batista

• schema: better 'version' error messages: wrong type and incorrect length (#2497)
  (LP: #1815812)

An expedited release

This is an expedited release, including some features, but more importantly the necessary fix to unbreak snap builds using classic confinement that use no base. These snaps essentially target core, which is based on Ubuntu 16.04.

New in this release

stage-snaps

This feature is equivalent to the stage-packages keyword but instead of using packages from the build environment's repositories, uses snaps hosted on the Snap Store.

The semantics are the same as those available for build-snaps. When declaring a snap to be staged, the snap will be retrieved from the Snap Store and unpacked into the the snap currently being built. The meta and snap directories from the snap will be available as meta.<snap-name> and snap.<snap-name> for the cases where assets from those locations are desired for reuse.

schema migrated from yaml to json

This has been done to make it easier to reuse in editors such as Visual Studio Code to get syntax/error highlighting in place. Here's how it would look like with the appropriate extensions in place:

Once this plugin is ready to use it will be available from the Snapcraft docs. In the meantime, an early preview is available.

New colcon plugin

This plugin enables the new build system that targets ROS2, it has been introduced in experimental form as the build system is actively being worked on by the OSRF.

These are the options the plugin offers for a part needing to build with colcon:

    - colcon-packages:
      (list of strings)
      List of colcon packages to build. If not specified, all packages in the
      workspace will be built. If set to an empty list ([]), no packages will
      be built, which could be useful if you only want ROS debs in the snap.
    - colcon-source-space:
      (string)
      The source space containing colcon packages (defaults to 'src').
    - colcon-rosdistro:
      (string)
      The ROS distro to use. Available options are bouncy and crystal (defaults to
      crystal), both of which are only compatible with core18 as the base.
    - colcon-cmake-args:
      (list of strings)
      Arguments to pass to cmake projects. Note that any arguments here which match
      colcon arguments need to be prefixed with a space. This can be done by quoting
      each argument with a leading space.
    - colcon-catkin-cmake-args:
      (list of strings)
      Arguments to pass to catkin packages. Note that any arguments here which match
      colcon arguments need to be prefixed with a space. This can be done by quoting
      each argument with a leading space.
    - colcon-ament-cmake-args:
      (list of strings)
      Arguments to pass to ament_cmake packages. Note that any arguments here which
      match colcon arguments need to be prefixed with a space. This can be done by
      quoting each argument with a leading space.

The issues and features worked on for 3.2 can be seen on the 3.2 launchpad milestone which are reflected in the following change list:

• many: support for stage-snaps (#2468) (LP: #1805214)
• project loader: do not leak a part's build-environment (#2472) (LP: #1815658)
• build providers: remove dead code (#2474)
• tests: disable spread colcon tests (#2476)
• ci: shallow clones for CLA checks on travis (#2477)
• meta: handle symlinked hooks (#2478)
• project loader: remove special LD_LIBRARY_FLAGS handling for classic (#2485) (LP: #1817300)
• sources: avoid marking changes to the snap directory as dirty (#2475) (LP: #1806746, #1816397)
• cli: clean up snapcraft push output (#2469) (LP: #1804439)
• cli: handle legitimate provider exec errors (#2483)
• schema: convert yaml jsonschema document to a json equivalent (#2448)
• tests: make before/after items an array in schema test (#2465)
• ruby plugin: support new download URL (#2466) (LP: #1815336)
• colcon plugin: new plugin (#2456) (LP: #1805213)
• colcon plugin: support build-time chaining (#2486) (LP: #1816565)

A snapcraft bug fix release

A bug fix release focusing on paper cuts

The issues and features worked on for 3.1.1 can be seen on the 3.1.1 launchpad milestone which are reflected in the following change list:

• ant, maven and gradle plugins: use correct defaults for jre (#2453)
  (LP: #1813637, #1813636)
• rust plugin: new link for rustup (#2438) (LP: #1662960)
• baseplugin: add a proper exception for cross-compilation support (#2454)
  (LP: #1808454)
• clean: error out on invalid or missing yaml (#2458) (LP: #1777501)
• lifecyle: avoid installation of snaps in docker (#2457) (LP: #1814148)
• ci: use non virt-enabled gce instances for 16.04 (#2461)
• extractors: fix typo in code comment (#2452)
• pluginhandler: handle removal of inconsistent files (#2450) (LP: #1813033)
• cli: retrieve error data from provider (#2455) (LP: #1793082)
• build providers: recreate instance if base changed (#2460) (LP: #1794506)
• catkin plugin: describe how to build all packages (#2459)

Welcome snapcraft 3.1

A new minor release building on top of the foundations laid out from the snapcraft 3.0 release.

Build Environments

It is now possible, when using the base keyword, to once again clean parts. To do so run:

snapcraft clean <part-name>

Cleaning individual steps from a specific part, previously provided by the --step option to clean, is being redesigned to be more intuitive and straight forward in its use.

Core

before and after

The before and after keywords, used for ordering service launching within a snap, are now properly supported in snapcraft.

Appstream extractor

The appstream metadata extractor can now properly handle tags inside the relevant nodes and properly filter xml:lang, such that:

  <description>
    <p>List:</p>
    <p xml:lang="es">Lista:</p>
    <ul>
      <li>First item.</li>
      <li xml:lang="es">Primer item.</li>
      <li>Second item.</li>
      <li xml:lang="es">Segundo item.</li>
    </ul>
  </description>

Is presented as the following description in snap.yaml:

List:

- First item.
- Second item.

Additionally, desktop files are now properly found from the appstream launchable entries or by falling back to legacy mode and inferring the desktop file from the appstream id.

Plugins

cmake

The plugin can now leverage build-snaps into the build environment, when any given build-snaps entry exists for a part that uses the cmake plugin, the plugin will make use of CMAKE_FIND_ROOT_PATH so that libraries and headers from that snap are preferred.

Additionally, cmake primitives are now used to drive the build instead of just calling make.

These features have already been used to create an initial set of KDE applications leveraging core18 as a base as described on the KDE apps at the snap of your fingers article.

rust

The rust plugin has been refactored in a backwards compatible way to work better with the non-legacy rustup tool.

Platforms

OS X

When using snapcraft with homebrew for the first time, if multipass is not found, the user will be prompted to install it before proceeding.

The issues and features worked on for 3.1 can be seen on the 3.1 launchpad milestone which are reflected in the following change list:

• cmake plugin: use native primitives (#2397)
• cmake plugin: use build snaps to search paths (#2399)
• static: update to the latest flake8 (#2420)
• project: state file path change (#2419)
• tests: do not use bash as a reserved package name on staging (#2423)
• nodejs plugin: fail gracefully when a package.json is missing (#2424)
• tests: use fixed version for idna in plainbox (#2426)
• tests: remove obsolete snap and external tests (#2421)
• snap: re-add pyc files for snapcraft (#2425)
• tests: increase test timeout for plainbox (#2428)
• lifecycle: query for multipass install on darwin (#2427)
• cli: fix usage string in help command (#2429)
• repo: document package purpose (#2390)
• extractors: better appstream support for descriptions (#2430)
• tests: re-enable spread tests on gce
• rust plugin: refactor to use the latest rustup
• tests: temporarily disable osx tests
• snap: add build-package for xml
• appstream extractor: properly find desktop files
• appstream extractor: support legacy launchables
• snap: add xslt dependencies for lxml
• repo,baseplugin: support trusting repo keys (#2437)
• schema: allow before and after (#2443)
• meta: make hooks executable instead of complaining they are not (#2440)
• build providers: remove SIGUSR1 signal ignore workaround for multipass (#2447)
• cli: enable cleaning of parts (#2442)
• tests: appstream unit tests are xenial specific
• tests: skip rust unit tests on s390x
• tests: use more fine grained assertions in lifecycle tests
• tests: remove rust revision testing for i386

Presenting snapcraft 3.0

The arrival of snapcraft 3.0 brings fresh air into how snap development takes place!

We took the learnings from the main pain points you had when creating snaps in the past several years, and we we introduced those lessons into a brand new release - snapcraft 3.0!

Build Environments

As the cornerstone for behavioral change, we are introducing the concept of build environments. These are configurations created for every snapcraft project you work on, tuned for the desired targets, ensuring API and ABI compatibility are in place for every binary through these build environments.

The way build environments work is by leveraging a feature of the snap architecture called bases.
A base is the building block that applications can rely on as a stable run time. At build time, the snapcraft tool ensures you are creating your applications inside an environment specifically tailored for this base.

To make the transition easy, the entire functionality for this new tool behavior is triggered by making use of the base keyword in snapcraft.yaml. For backward compatibility, all currently well known functionality is still available. You can omit the base keyword and continue working as you have previously done until you are ready to move to a newer or different stack provided by a different base.

The environment is encapsulated from the user during normal operations, but there are ways to step into the environment with the following build command options:

• --shell, runs upto the prior lifecycle step and drops into a shell instead in lieu of running the lifecycle step (e.g.: running snapcraft prime --shell will run up to the stage step and drop into a shell).
• --shell-after, runs upto the lifecycle step and and then drops into a shell (e.g.: running snapcraft prime --shell-after will run up to the prime step and then drop into a shell).
• --debug, drops into a shell inside the build environment when errors occur.

The below video shows an example of how the system behaves with the new functionality in place:

New platforms

With this release of snapcraft 3.0 we are happy to announce that MacOS is supported through homebrew. Moreover, the experience is transparent thanks to the use of build environments and its underlying technology.

Removed features

When using the base keyword in snapcraft.yaml the following, long ago deprecated, features are no longer available:

• wiki parts and the quirks in the code base to allow for certain corner cases introduced by this feature such as allowing / in parts.
• cleanbuild and triggering builds by use of lxd in certain environment variables.
• The prepare, build and install keywords used in parts are replaced with override-build and snapcraftctl, which also have the benefit of doing override- for pull, stage and prime as well.
• The snap keyword which was superseded by the prime keyword.
• When calling build commands through snapcraft, --disable-parallel-build is no longer available, it can be setup per part using the build-attributes property.
• Also, calling build commands through snapcraft, --use-geoip which affected stage-packages is no longer available.

The following plugins are no longer available when using the base keyword:

• tar-content, superseded by the dump plugin.
• copy, superseded by the dump plugin.
• jhbuild, it has too many dependencies against core.

Core features

The snapcraft 3.0 release brings the enablement of these core keywords for snapcraft.yaml with the use of the base keyword.

license

The license applicable to a snap is defined under the SPDX 2.0 format.
Validity of the license syntax is done using snap pack schema validation to ensure consistency across this snap ecosystem.

Wrapperless snaps

If you were part of the history of snaps since its conception, the idea of these wrappers probably make sense as they were useful when they were introduced to setup the environment appropriately. The architecture for the runtime has evolved in such a way where these wrappers do not make sense anymore as the primitives in the runtime have evolved into allowing a better design.

Although it is not the default today, the intention is to make this adapter value (full), the default behavior. Advantages of this design are that when entering a shell through snap run --shell the environment would be properly loaded through use of command-chain entries in snap.yaml

The recording below shows how the original command defined in snapcraft.yaml is now still the command that makes it to snap.yaml and the command-chain feature is used instead:

Extensions

The architecture and framework has been cemented into the snapcraft tool to grow declarative functionality in the snapcraft.yaml. We have done this to avoid repetitive tasks or require deeper knowledge of a target software stack.

Extensions have a unique property of being applied to the snapcraft.yaml itself, for them to be expanded and potentially used in lieu of the extension itself and make further project specific modifications.

You will be able to interact with extensions using the following commands:

• list-extensions, to view the available extensions.
• extension, to show information about the extension.
• expand-extensions, to display how the snapcraft.yaml will look like with the extensions
  applied.

Lifecycle

Prior to snapcraft 3.0, one had to go in and manually clean any part that was found to be dirty due to modifications in the code itself or the part definition in snapcraft.yaml. This was proven to be an unnecessary burden brought upon developers.

Taking this into account, the default action the snapcraft tool takes now is to rebuild parts, by either re-running without cleaning a lifecycle step upon changes for plugins that allow for it (through their underlying architecture) or automatically cleaning and re-running the necessary lifecycle steps for that part.

Here is snapcraft in action considering a project that has already been pulled:

Implicit source

Previously, if a source was not specified for a part, an implicit default source of . were set for parts. This was clearly a mistake that led to many confusing errors. Starting with version 3.0, if a plugins requires a
source to be specified, it will be required through the schema for which an appropriate error message will be raised. For plugins such as nil, a source is not really needed, so if it is not set, no action upon local sources (i.e.: .) will be taken.

Plugins

The majority of non deprecated or removed plugins have been reworked to be base aware.
Since the declaration of the base keyword is done manually by the user, some plugins have introduced semantic changes into how they operate as well.

Below is the set of plugins with interesting changes and new properties available to the user.

ant

These are the properties the ant plugin now operates with:

    - ant-properties:
      (object)
      A dictionary of key-value pairs. Set the following properties when
      running ant.

    - ant-build-targets:
      (list of strings)
      Run the given ant targets.

    - ant-version:
      (string)
      The version of ant you want to use to build the source artifacts.
      Defaults to the current release downloadable from
      https://archive.apache.org/dist/ant/binaries/.

    - ant-version-checksum:
      (string)
      The checksum for ant-version in the form of <digest-type>/<digest>.
      As an example "sha512/2a803f578f341e164f6753e410413d16ab60fab...".

    - ant-openjdk-version:
      (string)
      openjdk version available to the base to use. If not set the latest
      version available to the base will be used.

catkin

These are the properties the catkin plugin now operates with:

    - catkin-packages:
      (list of strings)
      List of catkin packages to build.
    - source-space:
      (string)
      The source space containing Catkin packages. By default this is 'src'.
    - include-roscore:
      (boolean)
      Whether or not to include roscore with the part. Defaults to true.
    - rosinstall-files:
      (list of strings)
      List of rosinstall files to merge while pulling. Paths are relative to
      the source.
    - recursive-rosinstall:
      (boolean)
      Whether or not to recursively merge/update rosinstall files from fetched
      sources. Will continue until all rosinstall files have been merged.
      Defaults to false.
    - catkin-cmake-args:
      (list of strings)
      Configure flags to pass onto the cmake invocation from catkin.
    - underlay:
      (object)
      Used to inform Snapcraft that this snap isn't standalone, and is actually
      overlaying a workspace from another snap via content sharing. Made up of
      two properties:
      - build-path:
        (string)
        Build-time path to existing workspace to underlay the one being built,
        for example '$SNAPCRAFT_STAGE/opt/ros/kinetic'.
      - run-path:
        (string)
        Run-time path of the underlay workspace (e.g. a subdirectory of the
        content interface's 'target' attribute.)
    - catkin-ros-master-uri:
      (string)
      The URI to ros master setting the env variable ROS_MASTER_URI. Defaults
      to http://localhost:11311.

go

These are the properties the go plugin now operat...

2.43.1

Hello Snapcrafters! The Snapcraft team is pleased to announce that version 2.43.1 is out.
This is a minor point release to fix some outstanding issues.

Contributions

This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to Evan Dandrea

New in this release

Core

Extensions

What was previously known as templates is now called extensions and the architecture on which this builds on is now pure python code to allow for future growth and decision making.

The rename takes place to convey that this functionality only extends an existing snapcraft.yaml and does not take part in modifying things that are only in place.

Containers

Build environments will soon be provided by multipass, guaranteeing more consistent results when builds are run from different machines. LXD containers (snapcraft cleanbuild today) will still be supported for existing projects.

In this release we catch up with snapd changes to continue offering a working snapcraft cleanbuild command.

Given the opportunity of modifying this code base, the logic to wait for cloud init has been improved.

Full list of changes

The issues and features worked on for 2.43.1 can be seen on the 2.43.1 launchpad milestone which are reflected in the following change list:

• lxd: support new style snap injection (#2222)
• snap: prepare override scripts to allow rebuilding (#2223)
• lxd: wait for cloud-init (#2227)
• storeapi: handle releasing to a curly braced branch (#2228)
• snap: use set-version and set-grade (#2230)
• lxd: proper filename set when using architectures (#2232)
• tests: cover manifest generation with review-tools (#2235)
• reporting: record the released version for errors (#2238)
• file_utils: find tool when using docker and deb (#2240)
• elf: better messaging on glibc ABI incompatibilities (#2241)
• spread: stop running catkin tests on 18.10 (#2221)
• snapcraftctl: run in isolation mode (#2224)
• templates: reimplement templates as python classes (#2226)
• templates: rename to extensions (#2233)
• cli: add list-extensions command (#2237)
• extensions: fix install path (#2236)
• reporting: improve messaging on errors (#2242)

Final notes

To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.

Happy snapcrafting!
-- Sergio and the team

2.43

Hello Snapcrafters! The Snapcraft team is pleased to announce that version 2.43 is out.

Contributions

This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:

• Michael Vogt
• Celso Providelo
• Daniel Llewellyn
• Emmanuel Leblond
• Paolo Pisati
• Jesse Sung

New in this release

Core

lifecycle

snapcraft now accurately identifies source and build changes and re-executes steps accordingly. This new mode is enabled through configuration in this release. To enable it now, open (or create) ~/.config/snapcraft/cli.cfg and add the following entry:

[Lifecycle]
outdated_step_action = clean

Take a look at the feature in action in the following video,

build providers

• Per project SSH key management support was added. Each project will have its own key generated.
• Snap injection logic has been improved and should be faster for the currently exposed build providers (i.e., multipass).
• Use of cleanbuild on OS X now defaults to using multipass transparently.
• Underlying image retrieving logic has been added to have a unique image available to build with any provider which would target a specific base (this is still under the covers and needs enabling).

error reporting

Snapcraft internal errors now prompt to send a report to Sentry, helping us identify the most pressing issues. An option to always report errors has also been added. Set SNAPCRAFT_ENABLE_SILENT_REPORT to a truthful value to automatically send the report.

The prompt asks if you always want to send error reports. If you choose this and change your mind, you can edit the option in snapcraft's configuration.

Take a look at this video to get a quick idea of the error reporting experience:

manifest

For better tracking of deliverables, if SNAPCRAFT_BUILD_INFO is set, the resulting manifest.yaml will contain the version of snapcraft used to create the snap.

templates

The templates machinery has made it into this release. However, no new template has been added as we want to carefully review any of these with all relevant stakeholders to provide the stability and consistency which was not fully achieved with shared parts.

CLI

templates

Although no template is available today, the commands to work with them are already available (these are working names for the commands and subject to change):

• template: Show contents of template.
• expand-templates: Display snapcraft.yaml with all templates applied.
• templates: List available templates (it is currently missing its counterpart list-templates).

Cleaner output

Tracebacks are now handled in a less verbose manner and stored to a file for inspection instead of printed to the screen.

The verbosity of output when using --debug has been reduced considerably as well, leaving the option with a more user-focused role (i.e., debug the actual project being worked on and not snapcraft itself).

The explicit traceback and the output previously seen when using debug can be enabled through use of an environment variable, SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes.

Plugins

go

The go plugin now knows not to install the debs if the well known snap is used.

Here's a video showing off the functionality:

kernel

As was done with Ubuntu based deb kernels, the kernel plugin now also installs the .config used at the root of the snap as config-$kernelversion.

rust

Given that they are well integrated into cargo, tests are now run for cargo builds.

jhbuild

The jhbuild plugin can now properly run as root and has been greatly simplified.

Full list of changes

The issues and features worked on for 2.43 can be seen on the 2.43 launchpad milestone which are reflected in the following change list:

• recording: expose the version of snapcraft (#2147)
• tests: add a fixture for OsRelease to simplify test setup
• recording: add the os-release ID and VERSION_ID to manifest.yaml
• nodejs plugin: update to the latest 6.x LTS point release (#2157)
• snap: use apt from the archive instead of compiling (#2156)
• build_providers: support for communicating with a qemu VM (#2155)
• many: refactor snapcraft.yaml loading out of load_config (#2160)
• tests: update codespell, the scope of checks and ordering of static
  tests (#2162)
• rust plugin: fix cargo builds and run tests (#2170)
• build_providers: add ssh key managemet to the qemu build provider (#2168)
• ci: disable osx tests until a new pyyaml is released
• build_providers: inject snaps when running from a snap (#2174)
• code: use black as the standard style (#2180)
• cli: reserve the --debug option for snapcraft projects (#2185)
• state: allow parametrization of the global state file (#2186)
• errors: enable sentry by default (#2187)
• file_utils: get_tool_path to always return an absolute path (#2193)
• errors: support keyboard interrupts (#2198)
• build_providers: add a build image setup facility (#2192)
• build providers: better injection logic (#2196)
• Revert "ci: disable osx tests until a new pyyaml is released" (#2213)
• providers: multipass by default on darwin (#2215)
• lifecycle: automatically stage dependencies (#2144)
• lifecycle: automatically clean dirty steps (#2145)
• travis: use LXD from 3.0 track (#2149)
• project_loader: process parts in consistent order (#2146)
• project_loader: allow loading null parts (#2153)
• tests: disable sentry (#2154)
• lifecycle: don't clean priming area if the snap is being tried (#2143)
• many: extract lifecycle ordering into own module (#2159)
• many: automatically redo step for specified part (#2152)
• tests: add lifecycle ordering tests (#2163)
• many: automatically detect dependency changes (#2165)
• project_loader: replace dict keys as well as values (#2166)
• {catkin,python} plugin: support cleaning (#2171)
• many: add shellcheck to static tests (#2172)
• lifecycle: detect local source changes (#2167)
• lifecycle: pass commands to containerbuild, not steps (#2178)
• cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated (#2179)
• pluginhandler: use uname from the host (#2177)
• store: properly handle disabled deltas (#2181)
• tests: create basic integration test spread infrastructure (#2173)
• tests: add spread suite for autotools plugin (#2182)
• tests: add spread suite for cmake plugin (#2183)
• spread: stop testing 17.10 (#2197)
• tests: add spread suite for copy plugin (#2199)
• tests: add spread suite for nil plugin (#2201)
• tests: add spread suite for kbuild plugin (#2203)
• kbuild plugin: stop modifying kconfigfile (#2204)
• tests: support running spread suite in autopkgtests (#2188)
• tests: add spread suite for meson plugin (#2205)
• tests: add spread suite for godeps plugin (#2200)
• tests: add spread suite for scons plugin (#2208)
• tests: add spread suite for catkin plugin (#2206)
• tests: add spread suite for waf plugin (#2210)
• cli: add inspect subcommand (#2184)
• tests: add spread suite for tar-content plugin (#2209)
• tests: add spread suite for ament plugin (#2211)
• tests: add spread suite for ruby plugin (#2212)
• project_loader: add basic template support (#2189)
• spread tests: vendor gotty
• spread tests: vendor kbuild-template
• spread tests: vendor hello
• sentry: support disabling error reporting (#2214)
• jhbuild plugin: allow running as 'root' (#2141)
• python plugin: add process-dependency-links to the pull_properties (#2190)
• ci: improve pr template and tools' ignored files list (#2191)
• tests: stricter match when running snapcraft revisions (#2195)
• go plugin: do not install go debs if go snap is used (#2194)
• kbuild plugin: read configs from source directory instead (#2202)
• kernel plugin: install .config as config-$kernelversion (#2207)

Final notes

To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.

Happy snapcrafting!
-- Sergio and the team