Uninative Release Process - Revision history

Tracy Graydon: /* Create the Release Directory */

2017-07-31T21:46:12Z

Create the Release Directory

← Older revision		Revision as of 21:46, 31 July 2017
Line 27:		Line 27:
	----		----

	If you are not using the uninative.py script for staging...		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_#>		On one of the build workers, or on the NAS, create the new release directory in <path-to-download-location>/uninative/<release_#>

Tracy Graydon: /* Create the Release Directory (if not using uninative.py for staging) */

2017-07-31T21:45:58Z

Create the Release Directory (if not using uninative.py for staging)

← Older revision		Revision as of 21:45, 31 July 2017
Line 24:		Line 24:
	i.e. python uninative.py -i 20170731-1 -n 1.7		i.e. python uninative.py -i 20170731-1 -n 1.7

	==== Create the Release Directory ~~(if not using uninative.py for staging)~~ ====		==== 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_#>		On one of the build workers, or on the NAS, create the new release directory in <path-to-download-location>/uninative/<release_#>

Tracy Graydon at 21:44, 31 July 2017

2017-07-31T21:44:55Z

← Older revision		Revision as of 21:44, 31 July 2017
Line 18:		Line 18:
	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.

	==== Create the Release Directory ====		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 not using uninative.py for staging) ====
	----		----

Line 54:		Line 60:

	Be careful, however, that a subsequent build has not clobbered the contents and that you are actually copying the version you think you are.		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 ====

Tracy Graydon at 17:56, 31 July 2017

2017-07-31T17:56:12Z

← Older revision		Revision as of 17:56, 31 July 2017
Line 21:		Line 21:
	----		----

	On the build ~~worker where~~ the ~~buildtools build occurred~~, create the new release directory in <path-to-download-location>/uninative/<release_#>		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 36:
	----		----

	~~Still~~ on the build worker ~~where~~ the build ~~happens~~, ~~the requisite files will be found in~~:		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		/home/pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/build/tmp/deploy/sdk

	~~Copy~~ the ~~following files to~~ the ~~release directory:~~		Be careful, however, that a subsequent build has not clobbered the contents and that you are actually copying the version you think you are.

	* i686-nativesdk-libc.~~host.manifest~~
	* i686-nativesdk-libc.target.manifest
	* i686-nativesdk-libc.tar.bz2
	* x86_64-nativesdk-libc.host.manifest
	* x86_64-nativesdk-libc.target.manifest
	* x86_64-nativesdk-libc.tar.bz2

Tracy Graydon: /* Build the tools */

2017-07-31T17:47:14Z

Build the tools

← Older revision		Revision as of 17:47, 31 July 2017
Line 9:		Line 9:

	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.		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.

	==== Create the Release Directory ====		==== Create the Release Directory ====

Tracy Graydon: /* Uninative Release Engineering Process */

2017-07-28T23:28:06Z

Uninative Release Engineering Process

← Older revision		Revision as of 23:28, 28 July 2017
Line 6:		Line 6:

	==== Build the tools ====		==== 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.		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.

	==== Create the Release Directory ====		==== Create the Release Directory ====
			----

	On the build worker where the buildtools build occurred, create the new release directory in <path-to-download-location>/uninative/<release_#>		On the build worker where the buildtools build occurred, create the new release directory in <path-to-download-location>/uninative/<release_#>
Line 24:		Line 26:

	==== Copy the Files ====		==== Copy the Files ====
			----

	Still on the build worker where the build happens, the requisite files will be found in:		Still on the build worker where the build happens, the requisite files will be found in:
Line 40:		Line 43:

	==== Publishing ====		==== 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.		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 ====		==== Tagging ====
			----

	Uninative releases are tagged in the following format:		Uninative releases are tagged in the following format:

Tracy Graydon: /* Uninative Release Engineering Process */

2017-07-28T23:21:23Z

Uninative Release Engineering Process

← Older revision		Revision as of 23:21, 28 July 2017
Line 5:		Line 5:
	Requests for a new uninative release will generally come from Richard Purdie.		Requests for a new uninative release will generally come from Richard Purdie.

	1. 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.		==== Build the tools ====

	2. On the build worker where the buildtools build occurred, create the new release directory in <path-to-download-location>/uninative/<release_#>		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.

			==== Create the Release Directory ====

			On the build worker where the buildtools build occurred, 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 19:		Line 23:
	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.		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.

	3. Still on the build worker where the build happens, the requisite files will be found in:		==== Copy the Files ====

			Still on the build worker where the build happens, the requisite files will be found in:

	/home/pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/build/tmp/deploy/sdk		/home/pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/build/tmp/deploy/sdk
Line 33:		Line 39:


	4. Tagging		==== 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 releases are tagged in the following format:
Line 43:		Line 53:
	Tags are pushed for both poky and oe-core.		Tags are pushed for both poky and oe-core.

			==== Announcements ====

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

	We currently do not formally announce uninative releases.

Tracy Graydon: /* Uninative Release Engineering Process */

2017-07-28T23:10:37Z

Uninative Release Engineering Process

← Older revision		Revision as of 23:10, 28 July 2017
Line 3:		Line 3:
	This document describes release engineering procedures for releasing new versions of Uninative.		This document describes release engineering procedures for releasing new versions of Uninative.

	* Where to obtain the files		Requests for a new uninative release will generally come from Richard Purdie.

	~~The Uninative files are found in~~ the ~~toolchain directory~~ of a given ~~build~~. ~~i.e. http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/toolchain/~~		1. 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.
	~~Richard Purdie will generally be the source for directing when~~ a ~~new release needs to happen and what branch/revisions to use for the~~ build~~, or identifying a specific existing release or release candidate~~.

	* What to ~~publish~~		2. On the build worker where the buildtools build occurred, 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.

			3. Still on the build worker where the build happens, the requisite files will be found in:

			/home/pokybuild/yocto-autobuilder/yocto-worker/buildtools/build/build/tmp/deploy/sdk

			Copy the following files to the release directory:

	* i686-nativesdk-libc.host.manifest		* i686-nativesdk-libc.host.manifest
Line 17:		Line 32:
	* x86_64-nativesdk-libc.tar.bz2		* x86_64-nativesdk-libc.tar.bz2

	* Where to publish

	~~Uninative releases are published at http://downloads.yoctoproject.org/releases/uninative/~~

	* Release Naming

	Releases are versioned sequentially in the format of '''M.m'''. i.e. 1.0, 1.1, 1.2. This release naming does NOT correspond to specific Yocto releases. Uninative releases may come from any build or Yocto release, as needed and are simply numbered incrementally.

	* Tagging		4. Tagging

	Uninative releases ~~should be~~ tagged ~~using a tag~~ in the following format:		Uninative releases are tagged in the following format:

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

	~~??? Signed~~ tags~~? oe-core and poky both? (Probably~~. ~~Need to confirm repo and signing)~~		Currently, Michael Halstead should be contacted for signing and pushing tags.

	~~??? Who pushes tags~~.		Tags are pushed for both poky and oe-core.


	* Announcements		5. Announcements

	We currently do not formally announce uninative releases.		We currently do not formally announce uninative releases.

Tracy Graydon: /* DRAFT */

2017-07-28T21:16:56Z

DRAFT

← Older revision		Revision as of 21:16, 28 July 2017
Line 2:		Line 2:

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

	~~=== DRAFT ===~~

	* Where to obtain the files		* Where to obtain the files
Line 15:		Line 13:
	* i686-nativesdk-libc.target.manifest		* i686-nativesdk-libc.target.manifest
	* i686-nativesdk-libc.tar.bz2		* i686-nativesdk-libc.tar.bz2
	* x86_64-nativesdk-libc.host.manifest *		* x86_64-nativesdk-libc.host.manifest
	* x86_64-nativesdk-libc.target.manifest		* x86_64-nativesdk-libc.target.manifest
	* x86_64-nativesdk-libc.tar.bz2		* x86_64-nativesdk-libc.tar.bz2
Line 40:		Line 38:
	* Announcements		* Announcements

	~~??? Do we need to, should we, announce to a mailing list?~~		We currently do not formally announce uninative releases.

	~~??? Do we need to~~ announce

Tracy Graydon: /* DRAFT */

2016-08-12T20:02:50Z

DRAFT

@@ Line 6: / Line 6: @@
 * Where to obtain the files
 * What to publish
 * Where to publish
 * Tagging
 * Announcements