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.
Created attachment 2818 [details] image-files.png
Created attachment 2819 [details] presenting-build-artifacts.png
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").
(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.
At the very minimum, we need to show iso and hddimg rootfs files, which are not currently displaying and therefore you cannot download.
Created attachment 3234 [details] Design - Displaying build artifacts
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.