Get project path for overrides

snapcraft
1

Hi,
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?

2

I currently use the following hack:

        # WORKAROUND:
        #   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
        #   https://forum.snapcraft.io/t/unable-to-determine-project-version-info-in-multipass-build-environment/10416
        if test -d /root/project; then
            packaging_source_tree_root_dir=/root/project
        else
            # parts/_part_name_/src
            packaging_source_tree_root_dir=../../..
        fi
3

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

4

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:

5

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:

    override-pull: |
      # 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 
        host)
          # 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
              parts|prime|stage)
                continue;;
              *)
                cp -r $ROOT_PROJECT_DIR/$dir $SNAPCRAFT_PART_SRC;;
            esac
          done
          ;;
        *)
          # 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
          ;;
      esac

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.

1 Like
6

I’ve filed a bug here: Bug #1824417 “Expose project directory path to the scriptlets” : Bugs : Snapcraft

7

@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.

8

Note that you can always add these as a new part’s source and call it in depending part’s scriptlets using $SNAPCRAFT_STAGE/path/to/scripts

9
1 Like