When building in Launchpad, the $SNAPCRAFT_PROJECT_DIR variable points to the folder that contains the working area for Snapcraft, for example, /build/snapcraft-root-framework-61e5de, which I would presume contains the prime, parts, project, etc folders. (Unconfirmed because I don’t want to spam builds to take a peek since it’s unnecessary anyway).
With the LXD backend, $SNAPCRAFT_PROJECT_DIR points to what would probably equivilently be /build/snapcraft-root-framework-61e5de/project, but locally on my own machine resolves to /root/project/, which is the folder that contains a copy of the folder containing snapcraft.yaml that’s being processed. The folder pointed to in Launchpad is not functionally equivilent to the folder pointed to in LXD.
Is it possible that the behaviour can be made consistent here, this is biting me in cases where I’m applying .diffs to source code by taking the .diff from $SNAPCRAFT_PROJECT_DIR and patching in $SNAPCRAFT_PART_SRC, since it works on e.g Github/locally/etc but not on Launchpad. From reading the documentation I can see how both folders could be considered appropriate, but personally think that pointing to the folder literally named “project” is probably more appropriate, and that maybe a hypothetical $SNAPCRAFT_WORKING_DIR is more appropriate for Launchpads interpretation.
I’ll try running a destructive mode build later and confirm whether the behaviour is the same there locally as in Launchpad, it’s good to see that you agree the value should point to the folder containing the snapcraft.yaml file because it’s the one that makes most sense to me.
Just to provide some context of why this is causing problems, it breaks e.g:
patch -i $SNAPCRAFT_PROJECT_DIR/patches/ROOT/ACliC.patch -p 1 ( which operates implicitly on $SNAPCRAFT_PART_SRC )
So having looked into this a bit more, my concerns with the $SNAPCRAFT_PROJECT_DIR are incorrect, when running with destructive-mode normally, the build takes place as expected with no errors, and $SNAPCRAFT_PROJECT_DIR does happen to make sense according to how it’s documented (even though the actual absolute folder threw me off, making me suspect the variable to be simply wrong originally, it’s still variable for a reason )
Instead, what appears to be the case is that the builds on Launchpad are being triggered with the snapcraft remote-build functionality, which only submits part of the folder it’s in (presumably, it’s only submitting whatever sources are explicitly mentioned in the snapcraft.yaml, in my case the patches folder isn’t explicitly mentioned as a part source), and as a result the build fails because the files referenced don’t actually exist remotely, whereas it likely would build fine using the Snapcraft Build Service. You can see this with the difference between the temporary git repo snapcraft creates vs the equivilent Github/locally
So the sky isn’t falling, the $SNAPCRAFT_PROJECT_DIR variable is working as expected and instead I need to refactor my project and possibly provide feedback against remote-build explicitly. For now though, all is well.
)
