Please add revisions of stage-snaps to manifest.yaml

[jhenstridge]

What needs to get done

At present if a snap uses stage-packages, the generated manifest.yaml file will be annotated with the versions of those packages used to build the snap. If a snap uses stage-snaps, no such annotation is added: while we can tell what channel was used, we don't know what revision that corresponded to at the time the snap was built.

Maybe something like the stage-packages syntax would be appropriate. Something like this?

    stage-snaps:
    - gnome-46-2404-sdk/latest/candidate=66

Why it needs to get done

This idea came up while trying to track down a bug where I had a known working revision of a snap and a known bad one.

My usual way of analysing these kinds of problems is to check the manifest.yaml file for each snap revision to find their Launchpad builds andthe corresponding git revisions. I can then inspect the changes between those revisions for possible causes of the bug.

In this case though, the snap used stage-snaps. It was obvious that the two snaps had been built with different revisions of the staged snap, but I had no way of telling what revisions they might be. The two manifests just told me they'd been built with the latest/candidate channel of the snap, which had changed between the two snap builds.

If the manifest contained the revision of the stage snap, I would have been able to drill down to look at what had changed in that snap.

[RafaelJohn9]

hey @jhenstridge , would love to be assigned this issue

[mr-cal]

I think this is a great idea. @RafaelJohn9, I'm not sure that this is an easy issue to tackle.

Currently, snapcraft copies the parts key verbatim into the manifest.

Craft-parts is responsible for downloading and unpacking the snaps in the pull step. During the pull step, craft-parts needs to capture the revisions and save them to the state manager. Then, it needs a new API call so snapcraft can retrieve staged-snaps for all parts. It would operate very similar to stage-packages.

What do you think, @cmatsuoka?