• Each project should have its own layer called meta-<projectname> to hold any and all changes and additions needed for that project.
• Each project should also define an image named <projectname>-image (rather than appending ost-image et al).
• Any changes to recipes of other layers (e.g. meta-ost) are carried out by appending the recipe in meta-<projectname> and should only be upstreamed later if deemed appropriate.

• meta-ost
  • meta-ost-ros
  • meta-ost-toradex
  • (meta-ost-ethercat (internal use only))
    • meta-<projectname>

meta-ost is the core layer for OST specific changes and should only contain recipes applicable to the MACHINES in it. It should not rely on BSPs that are not part of poky.

Recipes and MACHINES that rely on external BSPs should get their own layer named meta-ost-<vendor>, e.g. meta-ost-toradex for the colibri-imx6 based cb20, that requires the Toradex BSP. This second layer also contains layers such as meta-ost-ros and meta-ost-ethercat which don't rely on external BSPs, but provide optional software features. Recipes that require large or numerous dependencies – such as meta-ost-ros – should be split into its own layer as to keep the core build slim. Lastly, there is the meta-<projectname> layer. Every project using yocto should have its own layer to hold recipes and changes that are specific to that project. This structure ensures modularity and allows every project to customize the build without changing meta-ost or its companions.

The CI/CD pipeline is integrated into Gitlab and split into 2 parts: the layer and general configuration data.

The general configuration is located in its own repository under ci/yocto. It contains the scripts and config files necessary to easily build the images, as well as the gitlab CI template yocto.gitlab-ci.yml that serves as the basis for the layer's CI config.

The only layer currently equipped with a CI/CD pipeline is meta-ost ( gitlab). Its .gitlab-ci.yml includes yocto.gitlab-ci.yml and defines a job for each hardware platform and build stage (image, sdk, esdk), building each component and uploading it to gitlab as an artifact.

Any and all changes needed should first be made in meta-projectname>. This includes updating libraries from meta-ost et al. to a newer version than what is currently included in meta-ost.

Any recipes or changes that are specific to the project will stay in meta-<projectname>, while more general changes such as adding debug utilities to the image may be upstreamed to meta-ost or the appropriate vendor/technology specific layer (e.g. meta-ost-toradex).

Note that as stated above, meta-ost itself should only have minimal dependencies and its contents should apply to most (ideally all) builds. If in doubt, create a technology/vendor specific layer first. It can always be merged into meta-ost later.

Technology/vednor specific layers follow the same priciple as meta-ost in terms of submitting changes: Any changes should be implemented locally first – using meta-<projectname> – before they are upstreamed and/or a new layer is created.