On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
> On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
> > So you think having to send a request to a web service instead of just
> > parsing a string locally with one line of code is a good trade-off for
> > allowing dashes?
>
> This has been mentioned several times in this thread and I think there's
> a misunderstanding around this.
>
> So: When your tool/whatever works with modules it will have to have
> module metadata available in some form.
What if I don't want to work with modules at all, just with information
about modules?
What if I just want to write a tool that parses fedmsgs about module
builds in Koji and does something that depends on module names, streams
and versions? (e.g. some sort of changelog thing)
Your tool can use good old buildsys.build.state.change fedmsg with the well known name/version/release fields like this:
https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.stg.buildsys.build.state.change
https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.stg.buildsys.build.state.change
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. But in case your tool is doing general changelog per Koji build, it will work quite well with modules without you even noticing you are working with modules.
In case of tools, you can even query koji using its api and pass the name/version/release there, instead of NVR.
If you query Koji for the module build, you will actually find whole module metadata in "extra" part of the build.
In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils already sent in this thread.
Regards,
Jan Kaluza
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
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
