This turned out to be quite a yak-shave...

You may find it easier to review each commit individually. There were quite a few things I had to fix up to get all of this working.

Note that this patch series is a net increase in test coverage: previously there were two create_message() functions, neither of them covered. Now there is one and it is covered. There were previously two get_prev_results() functions of which only one was covered. Now there is only one (and it is still covered).

However the code path for producing Taskotron-compatible fedmsgs is still not covered. I have tested it by hand with fedmsg-relay and fedmsg-logger.

I would like to improve the tests further, to test sending real fedmsgs and STOMP messages, but I didn't want this PR to get even bigger. We could tackle that in #100.

Also just to clarify the migration path here:

My intention is that Fedora's deployment of resultsdb (which currently is sending to fedmsg with modname='taskotron') would be reconfigured to send the new generic messages to fedmsg with modname='resultsdb' and the Taskotron-compatible messaging would also be turned on with MESSAGE_BUS_PUBLISH_TASKOTRON=True.

In the Red Hat internal deployment we are not currently concerned about backwards compatibility in the messages and we are already using 'resultsdb' in the topic name, so we would simply continue doing that with the updated message structure.

Also note that this PR intentionally reverts the previous PR#91, PR#93, and PR#99 to restore the previous behaviour of the Taskotron-specific message publishing code.

@adamwill - this might be of interest to you

Haven't looked at it closely, but if I understand @dcallagh's description of what it does and the expected message topic correctly, SGTM.

Any other issues @jskladan?