Toaster database - Revision history

Michael Wood: /* What running a Build affects */

2016-02-10T17:52:14Z

What running a Build affects

← Older revision		Revision as of 17:52, 10 February 2016
Line 94:		Line 94:
	When you've configured your project in Toaster (using configuration data) and hit build on a Recipe two main things happen.		When you've configured your project in Toaster (using configuration data) and hit build on a Recipe two main things happen.

	'''1.''' Update or create the Recipe and Layer_Version in Toaster with any new information that we gathered by building it		'''1.''' Update or create the ''Recipe'' and ''Layer_Version'' in Toaster with any new information that we gathered by building it

	When a recipe is built we can update the configuration information in Toaster to be more accurate. e.g. if we have newer information than provided by the Layer index or if we're building a recipe in an imported layer for the first time we can update that Layer_Version to say what Recipes are in it.		When a recipe is built we can update the configuration information in Toaster to be more accurate. e.g. if we have newer information than provided by the Layer index or if we're building a recipe in an imported layer for the first time we can update that ''Layer_Version'' to say what ''Recipes'' are available in the layer or other metadata items which we have discovered by building (Summary, Description, Version, Licence, etc) we also create and update the packages which are provided by the recipe. These are created as ''CustomImagePackage'' objects as their use is for customising the packages installed in an image recipe ''(CustomImageRecipe)''

Michael Wood: /* Package */

2016-02-10T17:46:30Z

Package

← Older revision		Revision as of 17:46, 10 February 2016
Line 49:		Line 49:

	Package N - 1 Recipe		Package N - 1 Recipe

			==== CustomImagePackage ====
			This is a subclass of Package which contains 3 extra fields. ''recipe_includes'' are for keeping track of the packages which are included as part of the base recipe when it is built. e.g. the ''base_recipe'' has package busybox. ''recipe_excludes'' are packages which are normally included as defined by the base_recipe which have been explicitly asked to be excluded by the user. ''recipe_appends'' are the packages which are being appended to this recipe (think IMAGE_INSTALL +=)

			These objects are configuration data and are generated by running builds. When a build runs we create or update CustomImagePackages meaning that each build helps to create a pool of packages which are available to the user to add or remove based on the available recipes when creating a CustomImageRecipe

			CustomImagePackage N - N CustomImageRecipe

	=== Build ===		=== Build ===

Michael Wood: /* CustomImageRecipe */

2016-02-10T17:17:22Z

CustomImageRecipe

← Older revision		Revision as of 17:17, 10 February 2016
Line 42:		Line 42:
	==== CustomImageRecipe ====		==== CustomImageRecipe ====

	This is a special kind of Recipe which has ~~two~~ additional fields; base_recipe and project. base_recipe is the Recipe in which the Custom recipe has been based on and will ~~translate to~~ the ~~'required'~~ recipe to ~~inherit recipe metadata~~ from ~~and project because this custom recipe belongs to~~ a ~~certain project that has been created~~.		This is a special kind of Recipe which has three additional fields; base_recipe, last_updated and project. base_recipe is the Recipe which the Custom recipe has been based on and is the recipe which will be copied in when the Custom recipe is generated. The last_updated field is used internally to keep track of the last time the package list was last updated from a build.

	=== Package ===		=== Package ===

Michael Wood at 11:41, 9 November 2015

2015-11-09T11:41:57Z

← Older revision		Revision as of 11:41, 9 November 2015
Line 20:		Line 20:
	== Top level models ==		== Top level models ==
	There are many intermediate tables in Toaster's database, see diagram. Below are the most top level models on which everything else depends.		There are many intermediate tables in Toaster's database, see diagram. Below are the most top level models on which everything else depends.
			These models map to the metadata [http://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html#Concepts concepts] that make up openembedded/Bitbake.

	=== Layer and Layer_Version ===		=== Layer and Layer_Version ===
Line 89:		Line 90:

	When a recipe is built we can update the configuration information in Toaster to be more accurate. e.g. if we have newer information than provided by the Layer index or if we're building a recipe in an imported layer for the first time we can update that Layer_Version to say what Recipes are in it.		When a recipe is built we can update the configuration information in Toaster to be more accurate. e.g. if we have newer information than provided by the Layer index or if we're building a recipe in an imported layer for the first time we can update that Layer_Version to say what Recipes are in it.


	'''2.''' Make a copy of the Recipe(s) built and the Layer_Version(s) in the project at build time		'''2.''' Make a copy of the Recipe(s) built and the Layer_Version(s) in the project at build time

Michael Wood: /* Package */

2015-11-09T11:36:51Z

Package

← Older revision		Revision as of 11:36, 9 November 2015
Line 48:		Line 48:

	Package N - 1 Recipe		Package N - 1 Recipe


	=== Build ===		=== Build ===

Michael Wood: /* Target */

2015-11-09T11:36:41Z

Target

← Older revision		Revision as of 11:36, 9 November 2015
Line 71:		Line 71:

	Target 1 - 1 Build		Target 1 - 1 Build


	=== Project ===		=== Project ===

Michael Wood: /* Build */

2015-11-09T11:36:31Z

Build

← Older revision		Revision as of 11:36, 9 November 2015
Line 65:		Line 65:

	Build 1 - N Layer_Version		Build 1 - N Layer_Version


	=== Target ===		=== Target ===

Michael Wood at 17:36, 6 November 2015

2015-11-06T17:36:37Z

← Older revision		Revision as of 17:36, 6 November 2015
Line 55:		Line 55:

	Build 1 - 1 Target 1 - N Target_File		Build 1 - 1 Target 1 - N Target_File

	Build 1 - N Task		Build 1 - N Task

	Build 1 - N BuildArtifact		Build 1 - N BuildArtifact

	Build 1 - N LogMessage 1 - 1 Task		Build 1 - N LogMessage 1 - 1 Task

	Build 1 - N Variable		Build 1 - N Variable

	Build 1 - N Layer_Version		Build 1 - N Layer_Version

Line 94:		Line 99:
	The build property for these copied Layer_Versions is set to the current Build object. When this is set the objects down the relational chain (Layer_Version 1 - N Recipe 1 - N Packages) are considered part of the "build data" and should never be changed or edited after this point.		The build property for these copied Layer_Versions is set to the current Build object. When this is set the objects down the relational chain (Layer_Version 1 - N Recipe 1 - N Packages) are considered part of the "build data" and should never be changed or edited after this point.

	== What running lsupdates ~~(Layer source update)~~ affects ==		== What running lsupdates affects ==
	Layer sources provide the configuration data for Toaster from pre-generated configuration data. This allows us to to bootstrap Toaster to a state where you can select Recipes, Machines and Layers without having had the cost of downloading all of the Layers in openembedded and then parsing or building them. Toaster by default uses the [http://layers.openembedded.org Layer index] as a LayerSource to download this pre-generated configuration data~~. When lsupdates all the registered LayerSources run their update function~~.		When lsupdates (layer source updates) is run all the LayerSources run their update function. Layer sources provide the configuration data for Toaster from pre-generated configuration data. This allows us to to bootstrap Toaster to a state where you can select Recipes, Machines and Layers for your project without having had the cost of downloading all of the Layers in openembedded and then parsing or building them. Toaster by default uses the [http://layers.openembedded.org Layer index] as a LayerSource to download this pre-generated configuration data.

	=== Layer index layer source ===		=== Layer index layer source ===
	The [http://layers.openembedded.org Layer index] [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ source] has a ResT API which is called by the LayerIndex LayerSource which creates or updates if they exist Layers, Layer_Versions, Recipes and Machines.		The [http://layers.openembedded.org Layer index] [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ source] has a ResT API which is called by the LayerIndex LayerSource which creates or updates (if they exist) Layers, Layer_Versions, Recipes and Machines.

Michael Wood at 17:32, 6 November 2015

2015-11-06T17:32:26Z

← Older revision		Revision as of 17:32, 6 November 2015
Line 16:		Line 16:
	=== Project data ===		=== Project data ===

	~~Some~~ data ~~is designated~~ project specific, such as user imported ~~Layer,~~ CustomImageRecipe~~, Project variables and Builds~~.		This is the container for Configuration data and Build data. Additionally it contains project specific data such as user imported Layers and CustomImageRecipe.

	== Top level models ==		== Top level models ==
Line 48:		Line 48:

	Package N - 1 Recipe		Package N - 1 Recipe


			=== Build ===

			The Build model contains the metadata for reporting information about a Build. It is the top level object for many of the Build related models which contain output from a Build. The Build model also includes when the Build started and stopped, and the status of the build. Any data in toaster that has a build object related to it is considered Build data.

			Build 1 - 1 Target 1 - N Target_File
			Build 1 - N Task
			Build 1 - N BuildArtifact
			Build 1 - N LogMessage 1 - 1 Task
			Build 1 - N Variable
			Build 1 - N Layer_Version


	=== Target ===		=== Target ===

	When ~~you~~ build a Target object is created which ~~contains~~ one or more Recipe names~~, Build object for the build data~~ to ~~go into~~ and the Task that you're asking ~~bitbake~~ to do (default is build the recipe).		A target is the instruction on what to build that is sent to Bitbake. When a build is triggered a Target object is created which records the one or more Recipe names to be built and the [http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#tasks Task] that you're asking BitBake to do (no task supplied executes the default which is build the recipe).

	~~===~~ Build ~~===~~		Target 1 - 1 Build

	~~The Build model contains the metadata for reporting information about a Build. The includes when the Build started and stopped some of the configuration of the Build such as the Machine set.~~

	=== Project ===		=== Project ===

			The project model is the container for the configuration data of your current project, this includes the release, the Layer_Versions that you're using in your project and any project wide variables that are set when you trigger a build. Builds that you trigger on your project are also associated with the project.

			Project 1 - N Build N - N Layer_Version 1 - N Recipe 1 - N Package

			Project 1 - N ProjectLayers 1 - 1 Layer_Version

			Project 1 - N Layer_Versions (ImportedLayer)

			Project 1 - N CustomImageRecipe

	== What running a Build affects ==		== What running a Build affects ==

	When you've configured your project in Toaster (using configuration data) and hit build on a Recipe two main things happen.		When you've configured your project in Toaster (using configuration data) and hit build on a Recipe two main things happen.

Line 72:		Line 92:
	Copying creates a snapshot of that configuration data for the purposes of the build history. It also allows us to compartmentalise the build specific data e.g. what version the recipe was on, what the git checkout was at the time of build, the Machine set which may affect the recipes and packages etc		Copying creates a snapshot of that configuration data for the purposes of the build history. It also allows us to compartmentalise the build specific data e.g. what version the recipe was on, what the git checkout was at the time of build, the Machine set which may affect the recipes and packages etc

	The build property for these copied Layer_Versions is set. When this is set the objects down the relational chain (Layer_Version 1 - N Recipe 1 - N Packages) are considered part of the "build data" and should never be changed or edited after this point.		The build property for these copied Layer_Versions is set to the current Build object. When this is set the objects down the relational chain (Layer_Version 1 - N Recipe 1 - N Packages) are considered part of the "build data" and should never be changed or edited after this point.

			== What running lsupdates (Layer source update) affects ==
			Layer sources provide the configuration data for Toaster from pre-generated configuration data. This allows us to to bootstrap Toaster to a state where you can select Recipes, Machines and Layers without having had the cost of downloading all of the Layers in openembedded and then parsing or building them. Toaster by default uses the [http://layers.openembedded.org Layer index] as a LayerSource to download this pre-generated configuration data. When lsupdates all the registered LayerSources run their update function.

			=== Layer index layer source ===
			The [http://layers.openembedded.org Layer index] [http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/ source] has a ResT API which is called by the LayerIndex LayerSource which creates or updates if they exist Layers, Layer_Versions, Recipes and Machines.

Michael Wood at 15:55, 6 November 2015

2015-11-06T15:55:00Z

← Older revision		Revision as of 15:55, 6 November 2015
Line 32:		Line 32:
	Recipes contain the information about a collection or particular piece of software. This can be the ''name'', ''version'' and ''description'' and any distribution ''package''s are created by the Recipe.		Recipes contain the information about a collection or particular piece of software. This can be the ''name'', ''version'' and ''description'' and any distribution ''package''s are created by the Recipe.

	An example would be a recipe called myrecipe version 1.2 which produces 3 ~~packages~~ myrecipe-dev, myrecipe-dbg and myrecipe		An example would be a recipe called myrecipe version 1.2 which produces 3 Packages myrecipe-dev, myrecipe-dbg and myrecipe. Recipes are the objects which get built by BitBake.


	Recipe N - 1 Layer_Version		Recipe N - 1 Layer_Version
Line 50:		Line 51:
	=== Target ===		=== Target ===

	When you build ~~a recipe~~ a Target object is created which contains one or more Recipe names, Build object for the build data to go into and the Task that you're asking bitbake to do (default is build the recipe).		When you build a Target object is created which contains one or more Recipe names, Build object for the build data to go into and the Task that you're asking bitbake to do (default is build the recipe).

			=== Build ===

			The Build model contains the metadata for reporting information about a Build. The includes when the Build started and stopped some of the configuration of the Build such as the Machine set.

			=== Project ===


	== What running a Build affects ==		== What running a Build affects ==