Binary Distro Process

High Level Architecture

A binary distribution begins with creating a process that allows you to do consistent, deterministic builds. This process becomes cyclical over the life of the product. The general procedure involves: Setup the build (new configuration or restoration of the prior build configuration and artifacts), performing the build, verifying the results of the build, storing the artifacts for the next iteration, and publishing the artifacts for the end user to use.

PICTURE HERE

Everything starts with an overall system configuration. The following items will need to be captured as part of the Configs.

Description of Process

Layer Setup & Configuration

• Layer Setup
  • URLs
  • Commit IDs
• Configuration
  • bblayers.conf
  • local.conf

  USER_CLASSES += "reproducible_build"
  USER_CLASSES += "packagefeed-stability"
  USER_CLASSES += "buildhistory"
  DEFAULTTUNE = "<common tune>"
  DISTRO = "..."
  PACKAGE_CLASSES = "package_rpm"
  EXTRA_IMAGE_FEATURES – REMOVE debug-tweaks!
  BB_HASHSERVER = "auto"
  BB_SIGNATURE_HANDLER = "OEEquivHash"
  PRSERV_HOST = "localhost:0"
  INHERIT += "archiver"
  ARCHIVER_MODE[src] = "original"
  ARCHIVER_MODE[recipe] = "1"
  ARCHIVER_MODE[dumpdata] = "1"
  ARCHIVER_MODE[srpm] = "1"

Build Project

The project is built using a standard process/target. Depending on the purposes of the binary distribution, it may require one or more recipe targets or even a world build.

The results of the build will be a series of artifacts.

Artifacts

The following artifacts will be generated and stored as part of the build:

• Configuration
  • Layer URLs/Commit IDs (or copies of)
  • project configuration files (local.conf/bblayers.conf)
• Log(s)
  • Console Logs
  • Individual Build Logs
  • buildhistory
• Sources
  • Downloads
  • ARCHIVER output
• Sstate
  • prserver database
  • sstate-cache
  • hash equivalency database
• Package Repository
  • Repository Configuration
  • RPM Packages
• images
• eSDK / SDK

Test

A test pass is then executed. The first step should be an inspection of the logs (including build history) to verify the output is as expected. Next a series of tests will need to verify that the image(s) boot, RPM packages can be installed, upgrades from the first and last releases work properly, etc. Over time this test suite will need to be expanded to deal with issues found along the way.

Fix

In the case of a test failure, a fix for the failure will need to be created and committed. Failed artifacts will be discarded (not released) as part of this.

Release

In the case of a test pass, assuming it has been decided to release, the artifacts are published. Note, prior artifacts should never be removed from the publishing location. Some artifacts, like build history may be determined to be internal only, but generally everything can be released.

Restore Last Released Artifacts

Once a new build is determined to be needed, layers are updated, last released artifacts are restored and a new build is performed repeating the process.

EOL

Product End-Of-Life is declared and no further updates are released.