One of the remaining tasks for our initial deployment of taskotron is getting depcheck running and reporting proper results. This ticket is the tracker for all the bits left to make that happen.

When complete, depcheck should be triggered on bodhi update changes and run on koji tags. I see the process for depcheck execution/reporting in taskotron looking like the following (ignoring any delay in scheduling (eg. only running every X minutes), and assuming only i386 and x86_64 as arches for simplicity):

== Triggering ==

taskotron-trigger recieves a fedmsg indicating update creation or change (I'll call it FEDORA-2014-1234 to make it obvious that it's an update and not an nvr)

The output from this step in the process is that a new depcheck run is scheduled for the tag containing FEDORA-2014-1234 (f99-updates-testing-pending)

== Task Execution ==

This task is a bit more complicated than many of the others that we have written thus far, so breaking it up into several sub-tasks for description purposes.

=== Download Relevant Builds ===

• all builds in f99-updates-testing-pending (i386 and x86_64) are downloaded
• for this case, all builds in f99-updates-pending are also downloaded

While rare, it is possible for an update to skip the updates-testing repo if it gets karma fast enough before an updates-testing push is done. The only way I can think of to guarantee that we haven't missed something is to include updates-pending even if that's 99% likely to be covered by the releng-mashed updates-testing repo

=== Tag Processing ===
The input tag is processed to determine required yum repos for deps
* in this case, it would be f99, f99-updates, f99-updates-testing
* the downloaded builds from f99-updates-testing-pending are mashed to create i386 and multilib x86_64 repos

=== Run Depcheck ===

As we're downloading i386 and x86_64 builds in order to construct a multilib x86_64 repo, it makes sense to run both i386 and x86_64 runs at the same time instead of scheduling them separately

depcheck runs for i386 and x86_64 are started (order doesn't matter much)

• pass in the discovered yumrepos during prep in addition to the relevant mashed local repos

results are reported in terms of bodhi updates

• process the output to correlate rpms with updates prior to emitting TAP at the end of depcheck

=== Report Results ===
Results need to be sent to resultsdb and bodhi comments (for now, at least. bodhi comments will be going away before too long)