Version 2.42 of the snapcraft CLI is now available for testing in these forms:
As a snap
The snap is available in the candidate channel:
$ sudo snap install --candidate --classic snapcraft
Of, if you already have it installed:
$ sudo snap refresh --candidate snapcraft
As a deb
The deb is in the proposed pocket of xenial, artful, and bionic, tracked by the SRU bug LP: #1767016. More information on testing the SRU is available at https://wiki.ubuntu.com/Testing/EnableProposed.
Docker
All risk levels of the snap are available as tagged Docker images, so check out the candidate tag:
$ docker pull snapcore/snapcraft:candidate
Release notes
Core
multipass cleanbuild support
If you are a user of snapcraft cleanbuild and have multipass installed (snap install multipass --beta at the time of this writing) then you might be interested in trying out this new feature, currently triggered by a
feature flag. Try it out by running:
$ SNAPCRAFT_BUILD_ENVIRONMENT=multipass snapcraft cleanbuild
sunset remote persistent containers
The feature, hidden behind a feature flag of enabling a remote lxd instance to drive the build with local
mounts in place has been removed as a feature due to complexities and trimming of scope towards a
unified, working and sustainable interface. Given this was a feature flag and never left its experimental
stages, removing it was the right thing to do to remove any expectation that this will be driven further or
have user go through a bad experience when using it.
This does not affect using local persistent LXD containers, nor does it affect remote cleanbuilds.
Error reporting
When enabling the snapcraft CLI’s use of Sentry by means of setting the feature flag to SNAPCRAFT_ENABLE_SENTRY=on (perhaps in your ~/.bashrc) you will now have the option to
always send the traceback instead of being prompted.
architectures keyword
Previous releases of the snapcraft CLI supported an architectures keyword that one could use to specify the architectures on which the snap runs. However, for multiple reasons this proved to be a confusing feature that few could use successfully, so this release sees it reworked to better match user expectations. The architectures keyword has been restructured into a list of more explicit objects, specifying both build and run architecture(s):
architectures:
- build-on: [<build arch 1>, <build arch 2>]
run-on: [<run arch 1>, <run arch 2>]
If snapcraft is building on an architecture in build-on, it will use the corresponding run-on in the final snap, stating that it runs on those architectures. Please read the documentation for more details.
Plugins
dotnet
When using override-build, the dotnet plugin can now be used to override the plugin logic.
You can find the full list of changes over on the release notes
We would appreciate anyone trying out their common workloads with this release, and maybe some new ones as well!
