On Tue, Mar 20, 2018 at 3:18 PM, Kamil Paral <kparal@xxxxxxxxxx> wrote:
On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza <jkaluza@xxxxxxxxxx> wrote:Your tool can use good old buildsys.build.state.change fedmsg with the well known name/version/release fields like this:Initially I was very concerned about the idea of having to query Koji for each module to get NSVC, because in Taskotron we run ten thousand tasks per day and every unnecessary network request means slower execution, higher risk of failure and more logs to debug. We try to minimize the number of network requests as much as we can. However, if the structured metadata is/will be available in fedmsgs, I think I don't have a use case at hand that I could use to object to this. I still think it's a bad idea, though, and will bite us in the long run.That's staging, because it's easier for me to find the module builds there :).Unfortunatelly, Koji does not add "type" field there, so you cannot find out if that's module or not.Is that something that will get resolved soon? Because it seems like a big blocker to any automated processing. If we want to run some tasks just on rpms and some tasks just on modules, how do we distinguish that?
You can query the Koji for build id and check the type of a build.
I don't think that feature request is even reported to Koji upstream, because nobody needed that and I found that yesterday.
It is however not new situation. There is the same "issue" for "images". If you want to run some tasks just for RPMs and not for images, you have to do the filtering like this anyway. Therefore I don't really consider this as real blocker which needs fix urgently.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
