Should output be in plaintext or HTML? If we want links to failed runs, I think that HTML would be better.

There is a bug in resultsdb (this ticket) and because of that, it is possible that time queries will be off.

! In #221#6, @jsedlak wrote:
Should output be in plaintext or HTML? If we want links to failed runs, I think that HTML would be better.

In general, I'd prefer plaintext. Most email clients I'm aware of will make links in plaintext clickable and I'm not sure writing output in html would give us much here

Script is in [[ https://bitbucket.org/fedoraqa/ansible-playbooks | ansible-playbooks ]] repo, in fetch_activity branch in roles/taskotron-trigger/files [[ https://bitbucket.org/fedoraqa/ansible-playbooks/src/90f5092da93670aaa34fac769386cc2ed27b2963/roles/taskotron-trigger/files/fetch_activity.py?at=fetch_activity | here ]]. Output has this form:

python fetch_activity.py -u http://resultsdb-stg.cloud.fedoraproject.org/resultsdb/api/v1.0 -f http://resultsdb-stg.cloud.fedoraproject.org/ -t 12
libtaskotron results
====================
Generated on: dhcp-29-204.brq.redhat.com
From:         2014-06-20T00:40:04.149330
To:           2014-06-20T12:40:04.149330
Passed: 269
Failed: 62
Passed checks:
--------------
examplebodhi: 25
upgradepath: 132
rpmlint: 112
Failed checks:
--------------
examplebodhi: 11
upgradepath: 4
rpmlint: 47
Links to failed checks:
-----------------------
examplebodhi:
http://resultsdb-stg.cloud.fedoraproject.org/results/43055
...
upgradepath:
http://resultsdb-stg.cloud.fedoraproject.org/results/43046
...
rpmlint:
http://resultsdb-stg.cloud.fedoraproject.org/results/43065
...

It doesn't contain link to output log, but I have [[ https://bitbucket.org/fedoraqa/resultsdb_frontend/commits/b84171fb279bcc305a00896fd3a0200f7386ccd7 | sent patch ]] to resultsdb_frontend to show link to log in result detail.

Looks pretty good to me. A couple of things:

• argparse is generally preferred over optparse since our infrastructure is all python 2.7+ (Fedora and RHEL7)
• you don't need to rewrite that part, more for future reference
• the -h output and error message when no input are given could use a bit of improvement
• -t is the most in need of some more explanation to cover time range and the last X hours
• A little more sanity checking on the time span arg would be good
• error messages if the input format is incorrect

At some point in the future, I'd love to see this look for jobs which were scheduled but were aborted or crashed but that can wait for another day.

Can you post full output as a file attachment to this ticket?

! In #221#11, @tflink wrote:
* argparse is generally preferred over optparse since our infrastructure is all python 2.7+ (Fedora and RHEL7)
* you don't need to rewrite that part, more for future reference

Oh, I thought that we must also support python < 2.7.

{F2915}

I wrote some regexes for checking time span arg. I'm not sure if it's better to [[ https://bitbucket.org/fedoraqa/ansible-playbooks/src/dd093e319f25122b6635a3a1364c6db2a9f4599c/roles/taskotron-trigger/files/fetch_activity.py?at=fetch_activity#cl-97 | have our own regex ]] for it or to use some thirdparty library for it.

I wrote some regexes for checking time span arg. I'm not sure if it's better to have our own regex for it or to use some thirdparty library for it.

For this case, I'd rather not have deps unless it would save a significant amount of time. Which library did you have in mind?

For example [[ https://pypi.python.org/pypi/aniso8601/0.82 | aniso8601 ]] or [[ https://pypi.python.org/pypi/iso8601/0.1.10 | iso8601 ]]. I have written regex for checking correct format, but it doesn't handle all ISO 8601 features (for example timezones).

! In #221#11, @tflink wrote:
At some point in the future, I'd love to see this look for jobs which were scheduled but were aborted or crashed but that can wait for another day.

I think that current buildbot's JSON API isn't ready for it yet. As I have discussed on #buildbot, you can't query builds for selected time span with current API (someone on IRC wrote that "the API in 0.8.x is quite basic, in 0.9.x there will be much fuller API coverage..."). It seems that only way of how to do that is to query ALL builds and then filter it, which isn't nice...

OK, I haven't spent much time with buildbot's JSON api so I wasn't sure how reasonable that would be.

I'm good with the script as is - please merge it into master, close the remote branch you created and close the ticket when you're done.