| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
| software:linux:yocto:workflow [2021-09-21 13:58] – Moritz Lammerich | software:linux:yocto:workflow [2023-05-10 15:03] (aktuell) – Urs Graf |
|---|
| * 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 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). | * Each project should also define an image named ''<projectname>-image'' (rather than appending ''ost-image'' et al). |
| * Any changes to recipes other layers (e.g. ''meta-ost'') are carried out by appending the recipe in ''meta-<projectnmae>'' and only upstreamed if deemed appropriate at a later date. | * 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-ros'' | * ''meta-ost-ros'' |
| * ''meta-ost-toradex'' | * ''meta-ost-toradex'' |
| * (''meta-ntb-ethercat'' (internal use only)) | * (''meta-ost-ethercat'' (internal use only)) |
| * ''meta-<projectname>'' | * ''meta-<projectname>'' |
| |
| |
| 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. | 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-ntb-ethercat'' which don't rely on external BSPs, but provide optional software features. | 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. | 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. |
| |
| ===== CI/CD ===== | ===== CI/CD ===== |
| | |
| | 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 {{https://gitlab.ost.ch/tech/inf/public/ci/yocto | 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]] ({{https://gitlab.ost.ch/tech/inf/public/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. |
| |
| ===== Submitting changes ===== | ===== Submitting changes ===== |
| | |
| | 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. |
| | |
