The idea is that if you open a check detail like this:
http://taskotron-dev.fedoraproject.org/resultsdb/results/574102
the Log → link will point you to the result log specific to the current build/update (in this case bodhi update). So you won't see a lot of non-relevant info, just //your// results.

Some checks already create these per-build/update artifacts ([[ http://taskotron-dev.fedoraproject.org/artifacts/20150430/e4d9a016-ef32-11e4-bf7d-5254007dccf9/task_output/ | example ]]), but resultsdb don't know about them yet, so it's can't replace the Log link from a generic full task log to a specific //your// results log. We need to inform resultsdb somehow.

Try to come up with a good way how to do this. A reasonable approach seems to be to allow checks to provide an URL in their TAP output. Not a full blown URL, but just the suffix to point to the artifact they want. So, the process would be:
1. the check creates some per-item artifacts in $artifactsdir
2. the check creates TAP for each of the items, and puts a relative path/to/item.log URL into it
3. resultsdb understands this and sets the item result log link to be $artifactsurl + path/to/item.log (not part of this ticket)

Note: It might be a good idea also to allow to link to per-item directories, not just files (log files). That way the check can generate many per-item artifacts (e.g. logs, html reports, images, etc) and still easily link to all of them at once.

Design this properly and implement the changes needed in libtaskotron. After that is done, create tickets for upgradepath and depcheck to implement this. Create a ticket for resultsdb to implement this. Create a ticket for bodhi_comment_directive to link to resultsdb task detail page instead of directly to the full log.