We have done some good progress to record details from the snapcraft.yaml and the environment where it is build, that will be stored in the resulting
.snap for auditing. This post contains a good part of the journey:
So far, we are adding annotations to the source
snapcraft.yaml file and writing it to
prime/snap/snapcraft.yaml. Everything in prime ends up in the
.snap, so if you unpack the snap you will be able to inspect what happened during the build, and even re-build it.
During our sprint last month we had a little discussion about the name of this file, and some other details. To start, we have to choose if we want to put everything about this build manifest in
prime/snap/snapcraft.yaml, or if we want to make it a new file in
At the end of the discussion, @Saviq and @sergiusens were inclined for the
manifest.yaml option (please correct me if I’m wrong). But there are pros and cons of each option, so before implementing it we wanted to open the discussion for a wider audience.
If we put all the manifest data in an annotated
snapcraft.yaml, then there is no change required in snapcraft to rebuild. You unpack the snap, go to the unpacked directory and run snapcraft in there. The problem is that this annotated file needs to include additional information that we don’t want to have in the source
snapcraft.yaml, like the version of the snapcraft and core snaps installed in the build machine. So, the schema for allowed values and keywords of the source file will be a subset of what’s allowed in this
snapcraft.yaml that stored inside the
.snap. Then we have two files with the same name but different validation rules.
There were some reasons to not include information like
snapcraft-version in the source
snapcraft.yaml, like keeping it agnostic to the environment where it’s build as much as possible. But well, there’s always an option to reevaluate that too. It could be possible to ignore or warn about those values, and just take them into account (if possible) when running a cleanbuild.
But let’s consider the other option. If we put all the manifest info about the build in
prime/snap/manifest.yaml we don’t have to worry that much about the schema for the source yaml and the object yaml, they will just be different files and different schemas. We could just put the valid annotated
snapcraft.yaml inside the snap, and put all the additional information in the
manifest.yaml. Or just copy the source
snapcraft.yaml, and put all the annotations and extra data in the
The thing with this second option is that now we have two files for the rebuild. So for reproducible builds (or at least similar builds) we can’t just call snapcraft, we would have to modify snapcraft to accept a command like
snapcraft from path/to/manifest.yaml.
As always with software, everything is possible. We please leave your comments here, to make sure we make a good decision in the end.