Bug 9869

* Explanation of the issue

During a build, bitbake (with buildhistory enabled) provides some information about the files which were produced by a target. For example, building an image recipe like core-image-minimal produces a manifest file, image_license.manifest, which lists the kernel artifacts (bzImage, modules tarball) generated during the build.

It is also possible to infer which image files (ext4, ext2, tar.bz) were produced by a build by comparing the BUILDNAME with the image files in tmp/deploy/images/<arch>.

On the SDK artifact side of things, it is possible to determine which files in tmp/deploy/sdk belong to a build, again using TOOLCHAIN_OUTPUTNAME.

Toaster uses the above techniques to figure out which files are produced by a build, but the work-around required, as outlined below, make this process fragile and overly complex:

1. bitbake doesn't provide an event which unambiguously tells a listener where to get the locations of the files produced by a target.

The association between a target and the files it produces is heuristic at best: for example, a target with task "populate_sdk" and recipe "core-image-minimal" will produce SDK artifacts with a path in tmp/deploy/sdk whose basename starts with TOOLCHAIN_OUTPUTNAME. Toaster has to rely on these types of brittle heuristic to figure out where SDK and image files are.

2. Some files appear to have no explicit relationship with a build. An example would be the *-nativesdk-* files produced by a populate_sdk_ext task. There is nothing in the filenames of these files which unambiguously connects the file to a particular build, and no metadata file to connect targets to those files.

Again, Toaster looks for "-nativesdk-" files if a build ran a "populate_sdk_ext" task, which is expected to produce these types of file.

3. If bitbake has already produced the artifacts which a target would produce, it  doesn't overwrite or replace those artifacts. For example, you run "bitbake core-image-minimal", it finishes, then you run it again; the image files aren't reproduced by the second build, as they already exist.

While this is very sensible for the purposes of caching etc., it has the downside of meaning that postfuncs may or may not run for a given task. (In the example above, postfuncs on do_image_complete only run for the first build.) This makes it almost impossible to reliably read the locations of those files in postfuncs, as you can't guarantee the postfuncs will run. And, given that certain variables are only available with the values you need when run as postfuncs (e.g. TOOLCHAIN_OUTPUTNAME), it also means you can't just rely on the BuildCompleted event either, as you may not have access to the data required to find the files.

bitbake also doesn't give any information about what it *didn't* produce, meaning that a listener can only infer "I expect this build to produce files, as it's an image recipe, but it didn't, so perhaps the files already in the tmp/deploy/images directory are relevant to this build too". Again, heuristics which are prone to error.

Toaster manages this by looking for a "similar" build target which was run previously, and copies artifact details from that to the build which didn't produce artifacts. But this is again brittle and rests on making assumptions.

* Suggested solution

What would be better is if bitbake could notify listeners of the tasks it runs, and the files those tasks produce; in cases where a task doesn't run because it has been cached, the fact the task was skipped is still notified; and these notifications are made for every build, keyed to the BUILDNAME, so that a listener can get a definitive list of the image and sdk tasks which were/would have been run for a build, and the files those tasks did/would have produced (if they didn't already exist).

In an ideal world, there would be a one or more files which listed all the SDK and image files output by a build, each file keyed to the BUILDNAME, though I'm not sure if bitbake could produce this.