I work on a project with a which currently depends on a lot of override-* logic. In snapcraft 3 multipass the project is mounted on /root/project or ‘…/…/…/project’ relative, with --destructive-mode or snapcraft 2 style build it was ‘…/…/…’ relative.
Is there anyway we can get the project path to us in our overrides? If not can an environment variable be added to point to the project path?
I currently use the following hack:
# Allow fetching project revision in multipass build
# environment, which uses out-of-tree build and packaging
# source tree repo location can't be determined via environment
# Unable to determine project version info in multipass build environment - snapcraft - snapcraft.io
if test -d /root/project; then
I am really interested in knowing why you need this and not rely on the working directory for pull and build, which in the case of the former is part of the sources?
If these things sound strange, let me advise you to go to the latest snap release on stable and to set a base (core is supported) in your snapcraft.yaml
For my specific case I need to generate and append the packaging tree’s VCS commit hash to the upstream version string, previously I could simply just run
git -C .. describe but now that the part’s source tree isn’t under the packaging project tree it no longer works:
Not entirely sure if this is the same situation, but for me I was building a go app, which uses go modules, and some of the dependencies were not trivially available on the master branch as expected by the go plugin, and so using the go plugin would lead to snapcraft attempting to run
go get -t -d -v ./... in my project which would fail. That means that using the go plugin would lead to the pull stage failing, and so to override the pull stage in such a way that it works both locally with multipass and with build.snapcraft.io I had to implement the pull stage with:
# we have to do this currently because the default go plugin does
# go get -t -d -v ./... which fails because influxdb doesn't have the
# needed import path on the master branch which is what the go plugin
# tries to use
ROOT_PROJECT_DIR=$(dirname $(dirname $(dirname $SNAPCRAFT_PART_SRC)))
case $SNAPCRAFT_BUILD_ENVIRONMENT in
# for host build env we don't have a project specific dir
# so we have to copy everything, filtering out the
# snapcraft generated directories
for dir in $(ls $ROOT_PROJECT_DIR); do
case $dir in
cp -r $ROOT_PROJECT_DIR/$dir $SNAPCRAFT_PART_SRC;;
# other build environments we will have a project dir that contains
# only the files from the original project
cp -r $ROOT_PROJECT_DIR/project/* $SNAPCRAFT_PART_SRC
Perhaps this is a totally different problem I had, but implementing this
override-pull scriptlet would have been much easier if there was an environment variable available in the scriptlet that pointed to either
$ROOT_PROJECT_DIR/project (defined from the snippet above) in the case of multipass builds or
$ROOT_PROJECT_DIR in the case of build.snapcraft.io builds (or whatever else in the case of some other build environment i.e. lxd)
Also note that the snapcraft.yaml used base: core18, I was on the stable snapcraft release and the go code was in the same git tree as snapcraft.yaml and this particular part for the go code had
source: . which may or may not have led to the above problems.
@sergiusens we have scripts and other things in the project directory that get used in our override- scriptlets. These scripts don’t live under any snapcraft part source so the only place we can get to them is from the project directory. I think it would be helpful if we had an environment variable that pointed to the project directory.
Note that you can always add these as a new part’s source and call it in depending part’s scriptlets using