Documentation Production Workflow
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
- 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
- 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
- static code checks: https://github.com/priv-kweihmann/meta-sca
- Robert Berger
- Randy MacLeod