Hello!
We now have two proofs of concept to record details from the python and nodejs snaps. Now we want to jump two make two proofs of concept about recording details about the machine where the snap was built.
I will make a couple of PRs, one to record general information about the machine, and another to record all the packages installed.
Here we record uname -a into the manifest:
https://github.com/snapcore/snapcraft/pull/1528
@ratliff @tyhicks is uname the right information for you, or would you prefer something different to describe the machine?
This brings a couple of important questions.
First, the parts can be run in separate moments, so the machine can change between the build of two parts. We could even build the parts in completely different machines, with some work. So, I think that we should record the machine information for each part. But an alternative would be to just record this information during the prime step, and ignore the possibility of different machines building different parts.
The other question is about when to record the info. I think that the most relevant information to record is from the build step. We want information about how the snap was build. But other steps might be somewhat relevant too. For example, I can imagine a case in which version X of apt is installed during pull. Then we update apt to X+1, and we execute the build step. The results of building after pull with apt vX and after pull with apt vX+1 could be different. This scenario sounds not very likely to me, and not worth the complication to record the machine info in multiple steps; but I would like to hear more opinions.
To start the discussion, my linked branch records the machine details for each part, only during the build step.
This one records all the installed packages in the machine:
https://github.com/snapcore/snapcraft/pull/1529/commits/b5c6d399bf13aee81ae23da2582e03e32fa0a706
And here things start getting ugly when we record the details per part. The list of installed packages is pretty big, and having it in many parts is not nice. Maybe, we can post-process the manifest to check if all the parts have the same recorded values, and if so store them only once in the global section. Or, as mentioned above, we can just not record them per-part.
The output of uname -a is fine. I agree with Kyle in the PR that the hostname isn’t needed and can be omitted.
The Ubuntu kernel has a distro patch to put more specific package information into /proc/version_signature but, since it is a distro patch, that’s only going to be present while running under Ubuntu kernels. It could be handy if it was included when present.
I guess it makes sense to record the machine info for each part. That has the possibility of generating a lot of info but, as you say, the machine state could change between part builds.
I think that recording the info during the build is the most important thing. I don’t think there’s much value in recording the machine info in other steps.
Oh, I like the idea of comparing the machine info on a per-part basis and only storing what’s changed.
Thanks for all the comments @tyhicks. I will go through them in following PRs.
For this week, I’m adding the list of installed snaps in the host. Just like on the previous pr where we added installed-packages, this one adds installed-snaps:
https://github.com/snapcore/snapcraft/pull/1567/commits/2ac88fd66359b445e3311ca10ba0dc43a615f4ed
