linux/poky.git/bitbake/lib/toaster/toastergui, branch 2.2_M2

bitbake: toaster-tests: package count/size shouldn't show for non-image builds

2016-07-19T07:56:52+00:00

If a build doesn't produce any image files, the package count and size shouldn't be shown. Also add some metadata to build dashboard elements so it is clear what they're for, and so they can be queried by the tests. (Bitbake rev: 3d5090af4475b1d0bb56911a8e30abf9097c1b3c) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster-tests: add tests for build artifact display on build dashboard

2016-07-19T07:56:52+00:00

Add tests for display of image, kernel and SDK artifacts on the build dashboard, checking that the "Images" option in the left-hand menu and the "Build artifacts" section display correctly for different types of build. Also add metadata to elements on the build dashboard so it's clearer what they represent, and to assist in finding them in the tests. Add a method to the test helper to make it more convenient to check whether a single element matching a selector exists. [YOCTO #8556] [YOCTO #8563] [YOCTO #9500] (Bitbake rev: 644a888ce5a2141f2e6e1c22430e196b65cb1313) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: the customise image button shouldn't rely on targets

2016-07-19T07:56:52+00:00

The build dashboard customise image button (for creating a new custom image based on an image recipe used by a build) shouldn't rely on targets: whether a new custom image can be created or not depends on whether any of the recipes used by the build are image recipes. Modify the method used to determine whether a build has customisable images to look at the image recipes used during the build, rather than whether the targets run by the build refer to image recipes. (Bitbake rev: 6648876c91134bda8498b4f8d7ace9147ec0d985) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: add package manifest path to Target objects

2016-07-19T07:56:52+00:00

Store the path to the *.rootfs.manifest file for targets which generate images. A link to the package manifest is displayed in the build dashboard for targets which produce image files. Like the license manifest path, if a target would have produced the package manifest (but didn't, because it already existed), that path is copied from the target which did produce the package manifest. (Bitbake rev: 79b8e349a0da2ea6b97ad82daa5837e6dfffe0af) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: better display of targets which produced no images

2016-07-19T07:56:52+00:00

SDK targets (populate_sdk) produce SDK artifacts but no image files. Currently, these targets appear under the "Images" heading in the build dashboard, even though they aren't strictly image targets. Change the heading to "Build artifacts". Also remove the section which states that a build produced no image files: this is not correct for populate_sdk targets (those targets don't produce image files under any circumstances); and other changes mean that all targets which do produce images will now show those files. The check for whether to display the "Build artifacts" section also needs to change, as we show targets here which didn't produce any images but did produce SDK artifacts. [YOCTO #8556] (Bitbake rev: b4dce68045c4615e7a6a474e952f670721a3b54e) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: show manifests in their own section of the build dashboard

2016-07-19T07:56:52+00:00

In the build dashboard, add a section for manifests to each target, which will contain the license and package manifests for a target. As we don't record the package manifest (yet), just move the license manifest link to that section for now. (Bitbake rev: 58cb685b567a081834a605530957f165d35fcf5e) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: only show "New custom image" button for builds with image targets

2016-07-19T07:56:52+00:00

Add a has_image_targets() method to Build, and use that to hide the "New custom image" button on the build dashboard if a build has no targets which build images. [YOCTO #9514] (Bitbake rev: 3c4b053e44ea512ef2ced67289a7b0161db6ce9b) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: use has_images() methods to display images correctly

2016-07-19T07:56:51+00:00

In the build dashboard, we had issues with showing images correctly, as we were using the is_image property of targets to determine whether a target would have image files. This property can be set to True if a target refers to an image recipe (e.g. "core-image-minimal"), even if the task used in the build didn't produce any image files. By adding has_images() methods to the Target and Build objects, which count associated Target_Image_File objects, we can correctly determine whether a target has image files associated with it, and if any of the targets for a build has image files. This means that we can screen out the left-hand "Images" menu options for builds which contained image-related targets (e.g. "core-image-minimal") but which didn't produce any images (e.g. "rootfs" task). [YOCTO #9500] [YOCTO #9784] (Bitbake rev: f6bba0ff254d5ed3163151d4b938f3a43c9acb0a) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: improve scan for SDK artifacts

2016-07-19T07:56:51+00:00

SDK artifacts were previously picked up by toaster.bbclass and notified to buildinfohelper (via toasterui). The artifacts were then added to the Build object, so that it wasn't clear which artifact went with which target; we were also unable to attach SDK artifacts to a Build if they had already been attached to a previous build. Now, toaster.bbclass just notifies the TOOLCHAIN_OUTPUTNAME when a populate_sdk* target completes. The scan is moved to buildinfohelper, where we search the SDK deploy directory for files matching TOOLCHAIN_OUTPUTNAME and attach them to targets (not builds). If an SDK file is not produced by a target, we now look for a similar, previously-run target which did produce artifacts. If there is one, we clone the SDK artifacts from that target onto the current one. This all means that we can show SDK artifacts by target, and should always get artifacts associated with a target, regardless of whether it really build them. This requires an additional model, TargetSDKFile, which tracks the size and path of SDK artifact files with respect to Target objects. [YOCTO #8556] (Bitbake rev: 5e650c611605507e1e0d1588cd5eb6535c2d34fc) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie

bitbake: toaster: attach kernel artifacts to targets

2016-07-19T07:56:51+00:00

The bzImage and modules files were previously attached to a build, rather than to the target which produced them. This meant it was not possible to determine which kernel artifact produced by a build came from which target; which in turn made it difficult to associate existing kernel artifact with targets when those targets didn't produce artifacts (e.g. if the same machine + target combination was built again and didn't produce a bzImage or modules file because those files already existed). By associating kernel artifacts with the target (via a new TargetArtifactFile model), we make it possible to find all the artifacts for a given machine + target combination. Then, in cases where a build is completed but its targets don't produce any artifacts, we can find a previous Target object with the same machine + target and copy its artifacts to the targets for a just-completed build. Note that this doesn't cover SDK artifacts yet, which are still retrieved in toaster.bbclass and show up as "Other artifacts", lumped together for the whole build rather than by target. [YOCTO #8556] (Bitbake rev: 9b151416e428c2565a27d89116439f9a8d578e3d) Signed-off-by: Elliot Smith Signed-off-by: bavery Signed-off-by: Richard Purdie