Uninative Release Process

From Yocto Project
Revision as of 21:46, 31 July 2017 by Tracy Graydon (talk | contribs) (→‎Create the Release Directory)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Uninative Release Engineering Process

This document describes release engineering procedures for releasing new versions of Uninative.

Requests for a new uninative release will generally come from Richard Purdie.

Build the tools

Build the buildtools using default revision of master branch, unless given other specific criteria. The buildtools may also come from a full run of a nightly, but typically an explicit run of buildtools build happens.

To build the buildtools, go to the autobuilder and launch the build, selecting "True" for the option to deploy artifacts. The artifacts will be published under https://autobuilder.yocto.io/pub/buildtools/<build_ID>. The files you want to publish will be found in the /toolchain/i686 and /toolchain/x86_64 subdirectories. Please note that the url will be https://autobuilder.yoctoproject.org/pub/buildtools/<build_ID> if using the "old" autobuilder cluster.

Tip: if you aren't sure which build # you want, you can snag the build ID from the Publishing Artifacts/logs/stdio output for the build you triggered. The first line of that log will contain the full path to the artifacts on the NAS.

i.e. /srv/autobuilder/autobuilder.yoctoproject.org/pub/buildtools/20170731-1/buildtools

In the above example, 20170731-1 is the build ID. You can then look under https://autobuilder.yocto.io/pub/buildtools/ for the requisite build.

There is a script that will do the creation of the release directory and copying of files. It may be found here: http://git.yoctoproject.org/cgit/cgit.cgi/release-tools/tree/uninative.py. It is recommended to use the script, but if all else fails, the steps that follow this section detail the exact process that should be used to manually stage the release.

To invoke the script, simply use: python uninative.py -i <build_ID> -n <uninative release #>

i.e. python uninative.py -i 20170731-1 -n 1.7

Create the Release Directory

If you are not using the uninative.py script for staging....

On one of the build workers, or on the NAS, create the new release directory in <path-to-download-location>/uninative/<release_#>

Using 1.7 as an example...

On the "old" yoctoproject.org AB cluster, this would be: /srv/www/vhosts/downloads.yoctoproject.org/releases/uninative/1.7

On the "new" yocto.io AB cluster, this would be: /srv/autobuilder/downloads.yoctoproject.org/releases/uninative/1.7

You should use http://downloads.yoctoproject.org/releases/uninative/ as a reference to determine what the next version number should be.

Releases are versioned sequentially in the format of M.m. i.e. 1.5, 1.6, 1.7, etc. This release naming does NOT correspond to specific Yocto releases. Uninative releases may come from any build or Yocto release, so they do not align with any specific given Major/Minor/Point release.

Copy the Files

Copy the following files to the release directory (omitting the path):

  • toolchain/i686/i686-nativesdk-libc.host.manifest
  • toolchain/i686/i686-nativesdk-libc.target.manifest
  • toolchain/i686/i686-nativesdk-libc.tar.bz2
  • toolchain/x86_64/x86_64-nativesdk-libc.host.manifest
  • toolchain/x86_64/x86_64-nativesdk-libc.target.manifest
  • toolchain/x86_64/x86_64-nativesdk-libc.tar.bz2

An example of what the end result should look like may be seen here:


In the event that something happens with the buildtools build directory, such as you forget to select to deploy artifacts, you can find the artifacts on the build-worker on which the build happened, under:


Be careful, however, that a subsequent build has not clobbered the contents and that you are actually copying the version you think you are.


In most cases the sync out to the external mirrors will happen automatically. In the event that it does not, manually start the sync out. If assistance is needed with this, contact Michael Halstead.


Uninative releases are tagged in the following format:

uninative-<version>. i.e. uninative-1.5, uninative-1.6, uninative-1.7, etc.

Currently, Michael Halstead should be contacted for signing and pushing tags.

Tags are pushed for both poky and oe-core.


We currently do not formally announce uninative releases. Simply notify Richard Purdie and any other relevant people that the release is published.