Why need cache builds?

The code calling this method checks images from children to parents, so imagine you have images like this:

rhscl-httpd  -|
rhscl-nginx  -|---> s2i-base ---> rhel-server
rhscl-perl   -|

Then when you start checking the children images, you will call resolve_commit of s2i-base three times and the same happens for rhel-server.

With the KOJI_BUILD_CACHE, we query Koji maximally only once per image.

We could query even the call to Lightblue to get s2i-base image, but the information about this image in lightblue can change during the time, so the caching would be much complex. On the otherside the Koji build "source" data remains the same forever, so they can be cached.

This seems fine to me. @sochotni, any comments?

Looks good, one thought though - since we already have to have this fallback how about just getting rid of the lightblue part completely and just rely on brew data? That's always going to be available and will make the code simpler overall.

If you want to keep both though - +1 from me

Edit: Just one warning - the "source" property of build is only there if the build hasn't been garbage collected. If you want to get the config of garbage collected build you'd need to look at task parameters instead

@sochotni: I would rather still use LB data if data are available there, because it's faster. We already have that data and getting them for each build from Brew is always an extra request on top of what we already have.

@jkaluza OK, no problem. But please account for the deleted build by looking up the task parameters instead of source in buildinfo itself