Please find proposed format for taskotron fedmsgs below.
{ 'i': 1, 'msg': {'check': {'name': 'upgradepath', 'type': 'bodhi_update', 'item': 'wireshark-1.10.12-1.fc20', 'arch': 'x86_64'}, 'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name': 'wireshark'}], 'result': {'id': 123456, 'submit_time': '2015-01-27 14:22:53.584210', 'outcome': 'failed', 'summary': '...', 'job_url': 'http://resultsdb.fedoraproject.org/...', 'log_url': 'http://taskotron.fedoraproject.org/...%27%7D }, 'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d', 'timestamp': 1395760459, 'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new', 'username': 'taskotron' }
The 'packages' field would be used for all the packages that are relevant to the check which result is being sent in the fedmsg, so they can be returned by fedmsg.meta.msg2packages and searched on using datagrepper.
Thoughts?
Thanks, Martin
On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
Please find proposed format for taskotron fedmsgs below.
{ 'i': 1, 'msg': {'check': {'name': 'upgradepath', 'type': 'bodhi_update', 'item': 'wireshark-1.10.12-1.fc20', 'arch': 'x86_64'}, 'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name': 'wireshark'}], 'result': {'id': 123456, 'submit_time': '2015-01-27 14:22:53.584210', 'outcome': 'failed', 'summary': '...', 'job_url': 'http://resultsdb.fedoraproject.org/...', 'log_url': 'http://taskotron.fedoraproject.org/...%27%7D }, 'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d', 'timestamp': 1395760459, 'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new', 'username': 'taskotron' }
The 'packages' field would be used for all the packages that are relevant to the check which result is being sent in the fedmsg, so they can be returned by fedmsg.meta.msg2packages and searched on using datagrepper.
Looks quite good to me. :)
So depcheck results would include a long list of relevant packages?
On Wed, 28 Jan 2015 13:42:23 -0500 Ralph Bean rbean@redhat.com wrote:
On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
Please find proposed format for taskotron fedmsgs below.
{ 'i': 1, 'msg': {'check': {'name': 'upgradepath', 'type': 'bodhi_update', 'item': 'wireshark-1.10.12-1.fc20', 'arch': 'x86_64'}, 'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name': 'wireshark'}], 'result': {'id': 123456, 'submit_time': '2015-01-27 14:22:53.584210', 'outcome': 'failed', 'summary': '...', 'job_url': 'http://resultsdb.fedoraproject.org/...', 'log_url': 'http://taskotron.fedoraproject.org/...%27%7D }, 'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d', 'timestamp': 1395760459, 'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new', 'username': 'taskotron' }
The 'packages' field would be used for all the packages that are relevant to the check which result is being sent in the fedmsg, so they can be returned by fedmsg.meta.msg2packages and searched on using datagrepper.
Looks quite good to me. :)
So depcheck results would include a long list of relevant packages?
It could, yes. The native output format of depcheck is per-rpm but we've always considered updates to be the lowest-level unit against which depcheck reports because it doesn't make sense to fail only part of an update. However, I think we can add a list of affected packages to the fedmsgs emitted for depcheck results.
The thing I'm wondering is if there are interesting use cases which aren't well covered by this. Package-specific checks wouldn't be a problem, nor would image-based checks. The only thing I can think of that may not work so well is stuff like the gnome-installed-tests which aren't specific to a single package or a single deliverable. Would FMN allow for folks to subscribe to messages from a specific check or are only certain fields capable of triggering notification?
Tim
On Thu, Jan 29, 2015 at 08:53:22AM -0700, Tim Flink wrote:
On Wed, 28 Jan 2015 13:42:23 -0500 Ralph Bean rbean@redhat.com wrote:
On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
Please find proposed format for taskotron fedmsgs below.
{ 'i': 1, 'msg': {'check': {'name': 'upgradepath', 'type': 'bodhi_update', 'item': 'wireshark-1.10.12-1.fc20', 'arch': 'x86_64'}, 'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name': 'wireshark'}], 'result': {'id': 123456, 'submit_time': '2015-01-27 14:22:53.584210', 'outcome': 'failed', 'summary': '...', 'job_url': 'http://resultsdb.fedoraproject.org/...', 'log_url': 'http://taskotron.fedoraproject.org/...%27%7D }, 'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d', 'timestamp': 1395760459, 'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new', 'username': 'taskotron' }
The 'packages' field would be used for all the packages that are relevant to the check which result is being sent in the fedmsg, so they can be returned by fedmsg.meta.msg2packages and searched on using datagrepper.
Looks quite good to me. :)
So depcheck results would include a long list of relevant packages?
It could, yes. The native output format of depcheck is per-rpm but we've always considered updates to be the lowest-level unit against which depcheck reports because it doesn't make sense to fail only part of an update. However, I think we can add a list of affected packages to the fedmsgs emitted for depcheck results.
The thing I'm wondering is if there are interesting use cases which aren't well covered by this. Package-specific checks wouldn't be a problem, nor would image-based checks. The only thing I can think of that may not work so well is stuff like the gnome-installed-tests which aren't specific to a single package or a single deliverable. Would FMN allow for folks to subscribe to messages from a specific check or are only certain fields capable of triggering notification?
Yeah, we could write a specific FMN rule for specific taskotron checks. They are just little python functions that accept a message and return true or false.
See https://github.com/fedora-infra/fmn.rules/tree/develop/fmn/rules
qa-devel@lists.fedoraproject.org