QA » openQA Project

Could work. https://github.com/okurz/openqa_irc/blob/master/Bot/BasicBot/Pluggable/Module/OpenQA.pm is an examplatory place where one can integrate the transformation into "human-digestable" format. Maybe you want to try that?

I can try tomorrow.

Some of the dependencies of that IRC bot are missing (not in devel:languages:perl and some not even in devel:languages:perl:CAPN:*). I tried to install missing Perl modules via cpan but that failed with a permission error trying to install something under /usr/bin. I don't want to mess my system for this so I didn't proceed.

Maybe it is better to add this to https://github.com/openSUSE/suse_msg anyways? That one I had successfully running on my system before and all its dependencies are packaged.

So far we have:

[11:17] [Notice] -hermes an #openqa-events- openQA job finished with result failed: https://openqa.suse.de/t2390060

I could change that to:

[11:17] [Notice] -hermes an #openqa-events- openQA job finished with result failed (review outstanding): https://openqa.suse.de/t2390060

Then someone interested in those notifications could simply configure the IRC client to produce a notification for messages containing failed (review outstanding). That should be possible with Konversion. Not sure whether it is a common feature, though.

sure, sounds good. But maybe "pending" instead of "outstanding" due to the ambiguity? :)

Yes, it is ambiguous so "pending" would be better, indeed. PR: https://github.com/openSUSE/suse_msg/pull/6

@Marius: Tell me when the change in openQA is used in production so I can update the irc bot.

It is already deployed on OSD.

Apparently it doesn't work in production. E.g. on #openqa-events we get [13:19] [Notice] -hermes an #openqa-events- openQA job finished with result failed (None): https://openqa.suse.de/t2425829. The brace should contain the bugref or 'review pending'. I have actually tested it locally (see PR).

@dheidler Have you deployed the changes for the Python bot yet (and restarted the service)?

Seems like the None is emitted when there's no bugref:

[12:11] [Notice] -hermes an #openqa-events- openQA job finished with result failed (None): https://openqa.suse.de/t2430595
[12:11] [Notice] -hermes an #openqa-events- openQA job restarted: https://openqa.suse.de/t2430831
[12:11] [Notice] -hermes an #openqa-events- openQA job finished with result passed: https://openqa.suse.de/t2430997
[12:12] [Notice] -hermes an #openqa-events- openQA job finished with result failed (bsc#1073390): https://openqa.suse.de/t2429267

So likely just a mistake on the Python-side where my change is obviously already deployed.

I appreciate the work you did but I doubt we are there to have the user story fulfilled. If you prefer we can continue in another ticket but have to be senseful about what users of openQA ask for: Same as in #16276#note-15, Are you sure AC2 is covered? How about we talk in person next week in office when you address me?

Right, AC2 is not covered. So the case of carry-over must be distinguishable.

I have just added a flag to tell whether the bug was carried-over. But when writing the test for it I've noticed that this is actually not that useful. I would have to construct the rare (test) case where a bugref is present at the time the job fails but it hasn't been added via take over but instead by a user while the test was still running.

And thinking further, you actually don't even need to distinguish the carry over. If there's no bugref at the time the job failed you will get "review pending" on IRC. That implies that no bugref has been carried over. Otherwise you wouldn't get "review pending" and the carried over bugref instead. So just setup your IRC client to notify you if a message contains "review pending" and you're good. So AC2 is fulfilled, indeed.

Since I have implemented it anyways, we can still add an explicit "carried over flag" to the AMQP message if you like. Just the test for the negative case would be missing.