Common source options
Unless the part plugin overrides this behaviour, a part can use these
source keys in its definition. They tell snapcraft where to pull source
code for that part, and how to unpack it if necessary.
A URL or path to some source tree to build. It can be local (
./src/foo) or remote (
https://foo.org/...), and can refer to a directory tree or a tarball or a revision control repository (
source-type: git, bzr, hg, svn, tar, or zip
In some cases the source string is not enough to identify the version control system or compression algorithm. The source-type key can tell snapcraft exactly how to treat that content.
By default clones or branches with full history, specifying a depth will truncate the history to the specified number of commits.
Snapcraft will checkout a specific branch from the source tree. This only works on multi-branch repositories from git and hg (mercurial).
Snapcraft will checkout the specific commit from the source tree revision control system.
Snapcraft will checkout the specific tag from the source tree revision control system.
Snapcraft will checkout the repository or unpack the archive referred to by the
parts/<part-name>/src/but it will only copy the specified subdirectory into
Snapcraft will use the checksum specified to verify the integrity of the source. The source-type of the source needs to be a file (
rpm) and the algorithm either
sha3_512. Prepend the checksum with its type, e.g.
Note that plugins might well define their own semantics for the
keywords, because they handle specific build systems, and many languages
have their own built-in packaging systems (think CPAN, PyPI, NPM). In those
cases you want to refer to the help text for the specific plugin.
snapcraft help <plugin>