summaryrefslogtreecommitdiffstats
path: root/meta/files/layers.example.json
Commit message (Collapse)AuthorAgeFilesLines
* The poky repository master branch is no longer being updated.Richard Purdie2025-11-071-47/+0
| | | | | | | | | | | | | | | | | | | | | You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oe-setup-layers: make "path" optionalYoann Congal2025-11-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Layer names and path are often redundant. Allow users to omit the path key when it is equal to the layer name by using the layer name as a default value for its path. For example, from layers.example.json: "sources": { "meta-alex": { "path": "meta-alex" }, "meta-intel": { "path": "meta-intel" }, "poky": { "path": "poky" } }, Update the schema to stop requiring "path" and remove it in example for "meta-intel". (From OE-Core rev: 7f36f0526fae5a81f9bc02e16cc849a2b1ea5797) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/files/layers.schema.json: drop the layers propertyAlexander Kanavin2022-09-021-24/+0
| | | | | | | | | | | | | | | | | This is a leftover from one of the RFC iterations, where the property contained available machines, distros and templates. As all of those were dropped from the final version, there is no reason to list the layers either anymore. Normally this would be a backwards incompatible change, but as the layer setup itself was just merged, I think we can do a quick fixup :-) (From OE-Core rev: 64a774de0e154ef81f20853fec903b17d9985a72) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/files: add layer setup JSON schema and exampleJoshua Watt2022-09-011-0/+72
Defines a common schema for layer setup that can be consumed by tools to know how to fetch and assemble layers for end users. Also includes an example of the layer setup that constructs poky/meta-intel/imaginary product layer for reference. The schema can be used to validate a layer setup file with the commands: $ python3 -m pip install jsonschema $ jsonschema -i meta/files/layers.example.json meta/files/layers.schema.json (From OE-Core rev: 72740b5dd635579e373b4bfe6ccacfe6a02aa998) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Alex: I made the following modifications to Joshua's original commit: - moved the files from meta/lib to meta/files - the example json showcases a multi-repo, multi-layer setup instead of just poky - closer to a typical product - added oe-selftest that validates the example json against the schema using python3-jsonschema-native - the schema is modified so that: -- all lists (sources, layers, remotes) are replaced by objects keyed by 'name' properties of the list items. This allows using them as dicts inside Python, and makes the json more compact and readable. -- added 'contains_this_file' property to source object -- replaced 'remote' property with a 'oneOf' definition for git with a specific 'git-remote' property. 'oneOf' is problematic when schema validation fails: the diagnostic is only that none of oneOf variants matched, which is too non-specific. -- added 'describe' property to 'git-remote' object. -- removed description property for a layer source: it is not clear how to add that when auto-generating the json Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>