TipsAndTricks/TeamWorkflows: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(Initial documentation of "production" workflows)
 
 
(One intermediate revision by one other user not shown)
Line 10: Line 10:
== Goals ==
== Goals ==


* Quickly build images from pre-existing artefacts.
* Quickly build images from pre-existing artefacts on minimal hardware (e.g. laptops).
* Avoid networking issues fetching from some upstream hosts (i.e. great firewall)
* Avoid networking issues fetching from some upstream hosts (i.e. great firewall)


Line 16: Line 16:


* A mirror of sstate objects (i.e. contents of <code>SSTATE_DIR</code>) which the build machine can access via a uri (file://, http://, etc)
* A mirror of sstate objects (i.e. contents of <code>SSTATE_DIR</code>) which the build machine can access via a uri (file://, http://, etc)
* if using the example ''poky'' distro you can use the mirrors on the Yocto Project infrastructure at [http://sstate.yoctoproject.org sstate.yoctoproject.org]
** if using the example ''poky'' distro you can use the mirrors on the Yocto Project infrastructure at [http://sstate.yoctoproject.org sstate.yoctoproject.org]
* A fixed version of the metadata which matches the sstate mirror (if the metadata isn't identical there's a strong chance of sstate checksum mismatches which result in being unable to use the mirrored objects and having to build recipes and their dependencies)
* A fixed version of the metadata which matches the sstate mirror (if the metadata isn't identical there's a strong chance of sstate checksum mismatches which result in being unable to use the mirrored objects and having to build recipes and their dependencies)
* i.e. if using ''poky'' and the Yocto Project mirrors as above, use a tagged release
** i.e. if using ''poky'' and the Yocto Project mirrors as above, use a tagged release
* Make use of uninative, this fixed libc implementation ensures greater shared state object reuse for native recipes
* Make use of uninative, this fixed libc implementation ensures greater shared state object reuse for native recipes
* the ''poky'' distro makes use of uninative by default, it's highly recommended that you use uninative in your custom distro
** the ''poky'' distro makes use of uninative by default, it's highly recommended that you use uninative in your custom distro
* A mirror of the download sources (i.e. contents of <code>DL_DIR</code>) to use as a premirror
* A mirror of the download sources (i.e. contents of <code>DL_DIR</code>) to use as a premirror
* the sources used by the core Yocto Project layers are mirrored on Yocto Project infrastructure at [http://downloads.yoctoproject.org downloads.yoctoproject.org]
** the sources used by the core Yocto Project layers are mirrored on Yocto Project infrastructure at [http://downloads.yoctoproject.org downloads.yoctoproject.org]
* '''Note''': the ''poky'' distro uses the Yocto Project download mirror as a premirror for non-SCM fetchers by default
** '''Note''': the ''poky'' distro uses the Yocto Project download mirror as a premirror for non-SCM fetchers by default


== Configuration steps ==
== Configuration steps ==

Latest revision as of 15:37, 15 June 2017

Note: there's a bug with PREMIRRORS handling. For optimal use of this workflow you should be running with either Morty 2.2.2+/1.32, Pyro 2.3.1+/1.34



OE-Core image builder

How to configure an OE-Core system to build images from shared artefacts.

Goals

  • Quickly build images from pre-existing artefacts on minimal hardware (e.g. laptops).
  • Avoid networking issues fetching from some upstream hosts (i.e. great firewall)

Requirements

  • A mirror of sstate objects (i.e. contents of SSTATE_DIR) which the build machine can access via a uri (file://, http://, etc)
    • if using the example poky distro you can use the mirrors on the Yocto Project infrastructure at sstate.yoctoproject.org
  • A fixed version of the metadata which matches the sstate mirror (if the metadata isn't identical there's a strong chance of sstate checksum mismatches which result in being unable to use the mirrored objects and having to build recipes and their dependencies)
    • i.e. if using poky and the Yocto Project mirrors as above, use a tagged release
  • Make use of uninative, this fixed libc implementation ensures greater shared state object reuse for native recipes
    • the poky distro makes use of uninative by default, it's highly recommended that you use uninative in your custom distro
  • A mirror of the download sources (i.e. contents of DL_DIR) to use as a premirror
    • the sources used by the core Yocto Project layers are mirrored on Yocto Project infrastructure at downloads.yoctoproject.org
    • Note: the poky distro uses the Yocto Project download mirror as a premirror for non-SCM fetchers by default

Configuration steps

  1. Use own-mirrors to configure PREMIRRORS for all supported fetchers with a single mirror URL
  2. (optional) add extra protocol-url pairs to PREMIRRORS
  3. Add SSTATE_MIRRORS

Example site.conf

# Use Yocto Project source mirror for all sources
SOURCE_MIRROR_URL ?= "http://downloads.yoctoproject.org/mirror/sources/"
INHERIT += "own-mirrors"

# Add extra PREMIRRORS for non-upstream (Yocto Project) components
PREMIRRORS_prepend = "\
    https?$://.*/.* http://my-mirrors.example.com/sources/ \n \
    git://.*/.*     http://my-mirrors.example.com/sources/ \n \
"

# Use Yocto Project sstate mirror and project-specific sstate mirror
SSTATE_MIRRORS = "\
    file://.* http://my-mirrros.example.com/sstate/PATH;downloadfilename=PATH \n \
    file://.* http://sstate.yoctoproject.org/PATH;downloadfilename=PATH \n \
"

eSDK image builder

How to generate an eSDK to facilitate application development and custom image builds from an existing set of artefacts.

Goals

  • Fully contained Yocto Project environment
  • go from eSDK install to generated image in <10 minutes