Build environment options¶
Snapcraft can optionally use the following arguments to modify the build environment.
Snapcraft Argument |
Description |
Notes |
---|---|---|
|
Destructive mode. Designed to be used in scenarios where additional provisioning of the build environment is required. This is not recommended because the build could contaminate the host build environment. |
See destructive mode. |
|
Builds the snap using LXD rather than Multipass. This can potentially reduce resource usage, especially from a VM. |
Requires LXD. For more information, see Select a build provider. |
|
Configures HTTP proxy. Snapcraft will honor the |
None. |
|
Configures HTTPS proxy. Snapcraft will honor the |
None. |
|
Bind the |
Requires LXD or Multipass. Only available when building core22 snaps. |
|
Configure the build environment with ESM using specified UA token. |
Requires LXD or Multipass. Only works for snaps built on core22. |
|
Add the build manifest to the snap package in |
Snaps built on Launchpad will have this set automatically. For snaps newer than core22, the command-line flag is deprecated and removed. The environment variable will still work. |
Destructive mode¶
Destructive mode builds the snap directly on the machine where Snapcraft is run without launching a build container. It is not recommended to use this option because Snapcraft cannot control the build environment. It is especially not recommended to use a personal machine or in a shared environment, where operations like adding package repositories may be disruptive.
The build environment should match the snap base. For example, a core24 snap should be built inside of an Ubuntu 24.04 environment.
For core22 and newer snaps, the user must have root-level permissions so that they can do operations such as installing snaps and apt packages and adding package repositories without needing to use sudo.
While destructive mode can be used in CI to save time, using an OCI image or a LXD container is recommended. See snapcraft rocks for OCI images that can be used with Docker to build snaps. For projects in GitHub, the action-build workflow is a good option.