Documentation Production Workflow: Difference between revisions
From Yocto Project
Jump to navigationJump to search
(Initial version) |
(Ideas migrated from bug #14482) |
||
Line 1: | Line 1: | ||
This page gathers ideas to document a production workflow for developers... | This page gathers ideas to properly document a production workflow for developers... | ||
Initial ideas from Robert Berger, summarized and expanded by this mind mapping attachement: https://bugzilla.yoctoproject.org/attachment.cgi?id=4793 | |||
A developer workflow for production should be mentioned: | |||
* SDK for developer/bitbake for production build and Yocto/OE person | |||
* devtool for developer/devtool for Yocto/OE person | |||
== Build efficiency == | |||
* local source mirrors | |||
* strategies for handling the git cloned repos (use local branches and rebase vs bbappend ) | |||
== Software update solutions == | |||
SW update solutions ([[System Update]]) should be mentioned for production, since people are reinventing all the time what's already there. | |||
== Tracking image contents == | |||
* To be able to see what meta-layers/branch/commit-id were used to build the image and whether something was modified without being checked in: image-buildinfo.bbclass. You can see on https://hub.docker.com/r/yoctotrainer/app-container-tensorflow-oci how the output of image-buildinfo.bbclass and image-manifestinfo.bbclass looks like. | |||
* What packages are in the rootfs (without a package manager) | |||
** I use https://gitlab.com/meta-layers/meta-resy/-/blob/dunfell/classes/image-manifestinfo.bbclass to write /etc/image-manifest (all packages) into my rootfs | |||
== License compliance == | |||
* Something like the oss-review toolkit (https://github.com/tsteenbe/ort) could be used to help with license compliance. I am not sure yet whether this should be outside of the YP or integrated with it. | |||
== Hardening the production image == | |||
* cve-check.bbclass | |||
* static code checks: https://github.com/priv-kweihmann/meta-sca | |||
== Credits == | |||
Thanks to: | |||
* Robert Berger | |||
* Randy MacLeod |
Latest revision as of 15:43, 30 July 2021
This page gathers ideas to properly document a production workflow for developers...
Initial ideas from Robert Berger, summarized and expanded by this mind mapping attachement: https://bugzilla.yoctoproject.org/attachment.cgi?id=4793
A developer workflow for production should be mentioned:
- SDK for developer/bitbake for production build and Yocto/OE person
- devtool for developer/devtool for Yocto/OE person
Build efficiency
- local source mirrors
- strategies for handling the git cloned repos (use local branches and rebase vs bbappend )
Software update solutions
SW update solutions (System Update) should be mentioned for production, since people are reinventing all the time what's already there.
Tracking image contents
- To be able to see what meta-layers/branch/commit-id were used to build the image and whether something was modified without being checked in: image-buildinfo.bbclass. You can see on https://hub.docker.com/r/yoctotrainer/app-container-tensorflow-oci how the output of image-buildinfo.bbclass and image-manifestinfo.bbclass looks like.
- What packages are in the rootfs (without a package manager)
- I use https://gitlab.com/meta-layers/meta-resy/-/blob/dunfell/classes/image-manifestinfo.bbclass to write /etc/image-manifest (all packages) into my rootfs
License compliance
- Something like the oss-review toolkit (https://github.com/tsteenbe/ort) could be used to help with license compliance. I am not sure yet whether this should be outside of the YP or integrated with it.
Hardening the production image
- cve-check.bbclass
- static code checks: https://github.com/priv-kweihmann/meta-sca
Credits
Thanks to:
- Robert Berger
- Randy MacLeod