Hmm, I'm not sure about putting it to get_build. Maybe with option (btype=True), but definitely not without it. Most of calls to get_build are internal and we don't need to know it saving one join. It also needs some more added logic to relatively clean get_build function.

Maybe other option is to create condition in get_build_type. so, if buildInfo is already dict, get_build could be skipped. Then we would add it to all pre/postBuildStateChanges. It is still a lot of new code. Not sure if it is more effective to do it ahead or wait for consumer's additional call.

@mikem @julian8628 ?

I agree with Tomas here. There is no reason to change get_build. We already provide this data via getBuildType in the api.

The hub calls thepostBuildStateChange callback 15 different places. This is a lot of code to change.

Given that, it's not clear to me that this RFE is worth doing. The messages on the bus are not expected to provide complete information. They just provide a signal with the basic info.

On the other hand, if we were to go with your original suggestion, that would not require changing all the callbacks individually.

I guess the question is whether the extra join is a performance hit. Maybe Tomas and I are over-optimizing.

Given that, it's not clear to me that this RFE is worth doing. The messages on the bus are not expected to provide complete information. They just provide a signal with the basic info.

I initialized the original idea when I checked some Jenkins jobs with koji. Jenkins listens to the messages on the bus via JMS-messaging plugin, and it can use filters to limit the msgs by the fields in the msg body to a smaller scope. Usually, they only want to receive the events with one btype, e.g, rpm, or module. Adding this in msg eases the Jenkins job's work. it doesn't need to get all msgs and call koji APIs to get btype. Anyway, no one complains this so far :-P.

I originally suggested to change get_build because it is a straight approach, but I think we could call getBuildType in protonmsg then set build_type in buildinfo. It seems simpler and with less side effects.

PR 2934

Commit 9b45805 fixes this issue

Commit e689602 fixes this issue