Snapcraft.yaml reference

This is missing the service ordering parts which are already documented for The snap format .

Name Description
apps.
<app-name>.
before
optional
List of applications that are ordered to be started before <app-name>. Applications must be part of the same snap. (snapd 2.31+)
Type: list[string]
Requires daemon to be set as the app type.
apps.
<app-name>.
after
optional
List of applications that are ordered to be started after <app-name>. Applications must be part of the same snap. (snapd 2.31+)
Type: list[string]
Requires daemon to be set as the app type.

It would be nice if this document talked about the /root/parts/<part-name>/* subdirectories where relevant.

For example, parts.<part-name>.organize says A map of files to rename / the key represents the path of a file inside the part and the value represents how the file is going to be staged.

But if I shell into the build container and go to /root/parts/<part-name>/, I see these subdirectories:

  • build
  • install
  • run
  • src
  • state

Does organize copy/rename those files from src to build? From src to install? From build to install?

Similarly, does parts.<part-name>.stage copy files from build to install? Or install to /root/stage? Does parts.<part-name>.prime only copy from /root/stage to /root/prime, or does it get involved in /root/parts/<part-name>/ somehow?

The context that Iā€™d like to know all of this is that if I use say override-build and then run snapcraftctl build, Iā€™m left unsure what steps have been run, and where the files have been put (build or install or /root/stage/?).

It would also be great if sections like parts.<part-name>.override-build could talk about what exactly snapcraftctl build does. IIRC, it handles running parts.<part-name>.organize, so if you donā€™t run snapcraftctl build for whatever reason, the files donā€™t get organized.

Why do we need to edit the documentation in such a strange way instead of editing some md file on github? I donā€™t see any benefits in this approach, and many issues, like polluting this chat and needing to reference ā€œwhere the section says X and Y it actually should beā€¦ā€. I mean, this definitely doesnā€™t scale in the long term and seem to just become more and more confusing :exploding_head:

I completely agree that this is not a suitable way to collaborate on docs, and. Iā€™ve raised this as an issue both before and after the implementation. It seems that itā€™s the way that Canonical has decided to do things despite being unworkable/unscalable. Similarly the Ubuntu Discourse does the same thing for tutorials and docs specific to Ubuntu, also. Whenever Iā€™ve raised this issue it has been stated that itā€™s fine and wonā€™t be changing.

2 Likes

I created a thread for this, can you please write something to share your support? :blush:

@degville can you add layouts to the reference here and maybe link to the other page we already have about layouts too?

Yes, of course - thanks for letting me know. Iā€™ll update this post when itā€™s done.

Update: Iā€™ve added Layout to the above reference and also to the top-level metadata document. I think we missed this because layouts had been experimental for so long.

1 Like

missing refresh-mode: endure | restart?

1 Like

Thanks for letting us know. Iā€™ve added it above and also to the snapcraft app metadata document.

Instead of proposing changes as a message, we can also edit the wiki directly, by clicking the green icon in the first post :wink: image

1 Like

@degville can install-mode get documented here please?

Thanks for flagging this missing option. Iā€™ve now added it to the reference and other services-related docs.

there is no mention of setting plugs for hooks that are documented on https://snapcraft.io/docs/supported-snap-hooks

This threw me for a long time and would have been helpful to have been here

2 Likes

Thatā€™s a really good point - sorry it caused you to struggle, and itā€™s something that should be here. Iā€™ll add hooks to this document.

1 Like

Iā€™ve updated the base keyword to indicate that it is now mandatory to specify a base snap unless the type is set to gadget, kernel, or base.

1 Like

Thanks for the update, and for letting us know. That was a really useful addition.

The information for ā€œadopt-infoā€ WRT snapcraft 7 seems incomplete. This page states that only ā€œversionā€ is a mandatory field that can be assigned via ā€œadopt-infoā€. However, consider the source here:

So it seems that ā€œadopt-infoā€ is associated with, at a minimum, grade, version, summary and/or description. Can this be clarified?

Missing a hyperlink: https://www.freedesktop.org/software/systemd/man/systemd.service.html#RestartSec=

Now added - thanks for the suggestion/fix!

1 Like