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

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