For items like parts.<part-name>.organize, can we add to the description in which environment the file path in the key exists? For example with stage, I think it would be “In the key/value pair, the key represents the path of a file inside the part install directory and the value represents how the file is going to be staged”? This took some trial and error to figure out when doing an override-build first so I knew where to put my build artifacts to be reached by organize
Seems like for parts.<part-name>.source-type, a few of the allowed enum values get cut off and replaced by an ellipsis ... when viewing the documentation through snapcraft.io:
I figured tar would be an acceptable source type, but I could only verify this by clicking to view the discourse page instead. Could we potentially change the page setting so that longer code blocks are not truncated and replaced with an ellipsis and instead wrap to the next line?
The latter does not include ‘core’ as a possible snap type. Also, there seems to be no separate page devoted to the explanation of the snaps with the type core.
The “core” type is historical and only used for the “core” snap. No other snap should sport the “core” type. I’m not even sure snapcraft can build a “core” snap, I know the core snap itself is not built using snapcraft. This is for context, not saying that our docs shouldn’t be clearer on this.
I noticed that it is possible to set global environment variables for a snap via environment key in snapcraft.yaml, but it isn’t documented. This is very useful, because these environment variables propagate to all hooks and apps with fewer repetition.
The meta/snap.yaml file for a core22 based snap has the following:
Hello! Thanks so much for mentioning this, and you’re absolutely right. I have added this now, but I’ve also created a todo task to cover global environment variables in more detail.
The documentation for apps.<app-name>.restart-condition is broken, other values besides on-failure are cut off: “Defaults to on-failure. Other values are `[on-failure”.
Not only are they still mentioned here, they are the main source of reference for how to use the stage and prime part keywords, which seems a bit confusing now.
onto this page, filling any gaps between them. I made sure to resolve any contradictions between this source and the others. The format had to change as a result – a single long table resulted in scrolling without navigation, and it wasn’t an enjoyable experience.
I also gave it a new title to better reflect what readers will find here.
We plan to provide updates to the schema and its formatting in due time.