Snapcraft.yaml reference

Maybe the only accepted value is none? I’ve moved the part to the example values.

Can this page be added to the sidebar on the new docs site here: https://discourse-docs.staging.snapcraft.io/t/snapcraft-yaml-reference/4276

The format for snap.yaml is already there so I think this page should be as well.

(apologies if that is already planned and hasn’t been done yet)

1 Like

@degville I believe that request goes to you ^

Yes (thanks!). We’ve actually been talking about this the last couple of days, and I’m currently looking over the The snap format doc with a view to taking the same approach with snapcraft.yaml, and ultimately, adding a reference section to include both.

I can’t seem to edit, so I’m commenting. There are a lot of missing links. I think the “advanced grammar” ones should point to Snapcraft advanced grammar. Not sure about the others.

Thanks for flagging this. We did re-create the contents of this reference with fixed links and text, spread across 3 different pages (see the Snapcraft format). This is briefly mentioned in the first line of this doc.

However, this page remains because some users like to see everything in a single easily searchable place, so we need to sync back those fixes if we’re going to keep both (which I think we should).

2 Likes

The environment variables links are empty.

The reference content on this page has now been updated. Let us know if there are any mistakes/omissions!

@degville it seems the keys for adopt-info, apps.<app-name>.common-id, and parts.<part-name>.parse-info are not documented in the reference. In fact the entire adopt-info tech doesn’t have any documentation on docs.snapcraft.io

Thanks for letting me know! In a weird world of coincidence, I’m just about to push a few changes to Using external metadata (so it can be properly published and searchable) and noticed exactly the same thing. I’ll fix the omissions and get it all updated as soon as I can.

The top-level plugs documentation seems to contradict itself; the type is dict (and the text calls out specifically that it requires a dict), but the example is a list:

Many thanks for this. You’re absolutely right. It looks like the top-level plugs description has been confused with apps.plugs, etc. I’ll remove the examples for now.

Just take a note that the schema comes from:

According the schema here’s the accepted values:

I’ve updated the topic to reflect it.

1 Like

I wonder if this topic is superseded by Snapcraft top-level metadata, Snapcraft parts metadata, and Snapcraft app and service metadata? There’s less sense in maintaining two identical copies of the document and those topics are the ones that are directly accessible from the docs.snapcaft.io site.

If it is superseded we might want to mark this one obsolete and redirect people to the current docs.

Oh, now I noticed that this topic is actually mentioned in The snapcraft format - Documentation for snaps: Universal Linux packages:

though I’m still questioning the necessity of maintaining two separate documents with the same/similar content.

I do agree. As the new reference material is both in a new format and split into categories, we were waiting for feedback before removing or fully deprecating the large single reference page. A good moment for this may be when we bring over the REST API reference material which will need to be split in a similar way.

1 Like

I keep attempting to use this document as a reference, and I keep finding out that many of the references are deprecated (It is very prominent in Google searches). This is very frustrating.

1 Like

I think that this page is missing command-chain

1 Like

Thanks! I’ve just added the missing details.