Bug 8563

Summary: Improve detection and presentation of build artifacts
Product: [Build System, Metadata & Runtime] Toaster Reporter: Belen Barros Pena <belen.barros.pena>
Component: toasterAssignee: Elliot Smith <elliot.smith>
Status: RESOLVED FIXED QA Contact: Libertad <libertad.gonzalez.de.la.cruz>
Severity: enhancement    
Priority: Medium+ CC: belen.barros.pena, jessica.zhang, stanciux.mihail
Version: 2.0   
Target Milestone: 2.2 M2   
Hardware: x86   
OS: Multiple   
Whiteboard: GUI desing available
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
image-files.png
none
presenting-build-artifacts.png
none
Design - Displaying build artifacts none

Description Belen Barros Pena 2015-10-23 14:26:16 UTC 
Currently, build artifacts (apart from logs) are presented in the build dashboard in 2 mains areas:

1. an 'image files' list per image recipe built in a build
2. an 'other artifacts' section per build

The way we are splitting both types of artifacts (image files and other) doesn't seem particularly reliable. Here are some of the issues I've encountered: 

* other artifacts show artifacts from previous builds

* image files with no 'rootfs' in the image name get listed in the other artifacts section, instead of the image files list (e.g. iso, hddimg)

* Toaster gets confused when identifying image files for images that share most of their name (eg. core-image-minimal and core-image-minimal-dev, as can be seen in the attached presenting-build-artifacts.png) 

* On occasion, we seem to be missing artifacts (I've seen this with live image types and, in the attached presenting-build-artifacts.png, the 'other artifacts' section seems to be missing the .manifest file for core-image-minimal). 

We should review how we are detecting artifacts, and see if the accuracy can be improved. 

Presentation-wise, image files should also show the extension only (as shown in the attached file image-files.png): image names are all the same and very, very long.
Comment 1 Belen Barros Pena 2015-10-23 14:26:54 UTC 
Created attachment 2818 [details]
image-files.png
Comment 2 Belen Barros Pena 2015-10-23 14:28:01 UTC 
Created attachment 2819 [details]
presenting-build-artifacts.png
Comment 3 Elliot Smith 2016-03-27 11:21:33 UTC 
A couple of other notes:

1. In the build dashboard, in builds which include image targets and non-image targets (e.g. "bitbake zlib core-image-minimal"), the non-image targets are listed as images in the left nav menu.

2. Building two images targets in a single build results in all image files being associated incorrectly with the first target (possibly only when both targets have matching names, e.g. "bitbake core-image-minimal core-image-minimal mine").
Comment 4 Belen Barros Pena 2016-03-30 09:51:58 UTC 
(In reply to comment #3)
> A couple of other notes:
> 
> 1. In the build dashboard, in builds which include image targets and
> non-image targets (e.g. "bitbake zlib core-image-minimal"), the non-image
> targets are listed as images in the left nav menu.
> 
> 2. Building two images targets in a single build results in all image files
> being associated incorrectly with the first target (possibly only when both
> targets have matching names, e.g. "bitbake core-image-minimal
> core-image-minimal mine").

Good catch! None of those two should be happening.
Comment 5 Belen Barros Pena 2016-04-18 12:58:10 UTC 
At the very minimum, we need to show iso and hddimg rootfs files, which are not currently displaying and therefore you cannot download.
Comment 6 Belen Barros Pena 2016-06-13 16:16:55 UTC 
Created attachment 3234 [details]
Design - Displaying build artifacts
Comment 7 Elliot Smith 2016-06-17 12:39:38 UTC 
Belen, in "Design - Displaying build artifacts", you show a build which produces both images and SDK artifacts. However, it is possible to run a build which only produces SDK artifacts, but which still uses image recipes (e.g. "bitbake core-image-minimal -c populate_sdk"). In this case, would we just show the part of the design for the SDK artifacts, missing out packages/image files/manifests?

Also, how do you go about producing the x86_64-nativesdk-pokysdk-linux* artifacts shown in the design? I only get the poky-glibc-x86_64-core-image-minimal-i586-toolchain-2.1+snapshot* files if I do populate_sdk.