This ticket had assigned some Differential requests:
D1180

@ralph says the changes are going to be needed sometime between F26 branch and GA. Aiming at F26 alpha sounds feasible to me.

talking to some of the modularity folks, it sounds like the following information is needed out of the fedmsg:

• msg['name']
• msg['version']
• msg['stream']
• msg['modulemd']

It sounds like this will be used to construct a rpm repo url.

edit: fixed typo

For me, it would be best to get whole raw fedmsg and then I'll do whatever I want.
Actually it is workaround, that in fedora there are no real build (via OSBS or whatever). and @jkaluza pointed me, that I can construct actual repo position from these data.

Chatting in #fedora-qa, it sounds like name-stream-release will have enough information for now.

At the moment, passing in the raw fedmsg isn't really practical due to how the bits of taskotron work together. The design is such that the task doesn't parse fedmsgs on its own. There has been [[https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/thread/PVMAL2YXAZ7LBWEKYKUH2XB25B63YVNO/|discussion on making this easier]] but that'll require code changes.

If this "format" ends up being used elsewhere, it will need to be figured out and/or bikeshedded by folks who know more about the topic at hand but for now, we'll be using - as the delimiter between name, stream and release as the ITEM.

yes, it could be enough. This could just simplify code like constructing various variables for tests like:
I would like to know module name
I would like to constrcut RPM repo in koji
I would like to have link to modulemd file
I would like to know basruntime version

I can construct it, but less info provided by that taskotron, causes bigger amount of code on side of consumers

@tflink Just for clarification, what contains fedmsg structure? Would it be able to parse it from msg?
Some time ago, I have played with the-new-hotness and rebase-helper. We parsed fedmsg and analyze the new upstream version.

Thanks
Petr

It is not necessary now, there will be "name", "stream", "version"
I've adapted my framework to use fedora PDC, so I'm able easily filter these data, including actual modulemd file