The Launchpad build service fails to recognize a snapcraft.yaml file that is a symbolic link in a Git source tree and reports the error: The top level of snapcraft.yaml from ~jgneff/+git/openjdk:beta is not a mapping For example, see the snapcraft.yaml symbolic link below: index : ~jgneff/+git/openjdkf https://git.launchpad.net/~jgneff/+git/openjdk/tree/snap?h=beta&id=ad1a2188f8fd6ad7aca0812b76a65f7b864277cd The failure occurs only when building a snap from a Git branch on Launchpad. All other builds work fine, such as when building automatically from the main branch on GitHub to the edge channel and when running remote builds with the 'snapcraft remote-build' command. It seems to occur only when trying to build the snap directly from a Git repository branch on Launchpad. I want to use a symbolic link for the snapcraft.yaml file to solve a problem with the Git workflow. I have to maintain three permanent branches for each of the three channels, with the main branch building into the edge channel, the beta branch building into the beta channel, and the candidate branch building into the candidate channel, which can then be promoted to the stable channel. Each of these channels track a different upstream repository and branch for the development, early access, and release versions of the software being packaged. The problem is that almost all of the important changes are in the snapcraft.yaml file itself, so when you change the file on main and merge into the other two branches, you always get merge conflicts and have to re-do the correct repositories, branches, and version numbers manually over and over again. By making it a symbolic link, I can put the snapcraft.yaml file for all three branches under the 'snap/local' directory, and each branch can have its own symbolic link pointing to the correct actual file: Under the 'snap' directory: snapcraft.yaml -> local/edge.yaml (for the main branch) snapcraft.yaml -> local/beta.yaml (for the beta branch) snapcraft.yaml -> local/candidate.yaml (for the candidate branch) With that setup, I can test all three releases on the main branch by temporarily changing the symbolic link, and when I merge the main branch into beta or candidate, there are no merge conflicts, and I don't wipe out any important source, source-branch, or version fields in the YAML file.