Uninative Release Process: Difference between revisions
| (3 intermediate revisions by the same user not shown) | |||
| Line 17: | Line 17: | ||
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. | 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 ==== | ==== Create the Release Directory ==== | ||
---- | ---- | ||
On the build | 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... | Using 1.7 as an example... | ||
| Line 36: | Line 44: | ||
---- | ---- | ||
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: | |||
/ | http://downloads.yoctoproject.org/releases/uninative/1.7/ | ||
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: | |||
/home/pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/build/tmp/deploy/sdk | |||
Be careful, however, that a subsequent build has not clobbered the contents and that you are actually copying the version you think you are. | |||
==== Publishing ==== | ==== Publishing ==== | ||
Latest revision as of 21:46, 31 July 2017
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:
http://downloads.yoctoproject.org/releases/uninative/1.7/
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:
/home/pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/build/tmp/deploy/sdk
Be careful, however, that a subsequent build has not clobbered the contents and that you are actually copying the version you think you are.
Publishing
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.
Tagging
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.
Announcements
We currently do not formally announce uninative releases. Simply notify Richard Purdie and any other relevant people that the release is published.
