Taskotron Fedmsgs Format

[Ralph Bean]

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 at 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/...'} },
> > >    '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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20150129/482b1f1c/attachment.sig>