Add support for choosing trigger based on config value
ClosedPublic

Authored by mkrizek on Apr 3 2014, 1:56 PM.

Details

Summary

Fixes T114

Test Plan

run fedmsg-hub according to instructions in readme.rst

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
tflink accepted this revision.Apr 3 2014, 2:45 PM

It'd be nice to see some tests around this but that's not strictly needed, I suppose

mkrizek updated this revision.Apr 4 2014, 11:27 AM

Add simple tests

mkrizek updated this revision.Apr 4 2014, 11:28 AM

Base it on the correct branch this time?

mkrizek updated this revision.Apr 4 2014, 11:31 AM

Name the test class properly

ralph added inline comments.Apr 4 2014, 1:27 PM
jobtriggers/triggers.py
49

(I thought I left this comment earlier, but I must not have hit submit...)

This line lead to some confusion.

Say a user puts type = Wat in the config file. Taskotron will load and start without an error message, and the user will actually get a StreamTrigger. (More realistically, imagine that the user has put type = BuildBotTrigger. That's a typo where they actually meant BuildbotTrigger).

Perhaps this should raise a KeyError if the exact trigger name is not found. Something like

return _triggers[trigger_type]()
kparal added inline comments.Apr 4 2014, 1:44 PM
jobtriggers/triggers.py
49

TaskotronConfigError might be suitable for this.

mkrizek added inline comments.Apr 4 2014, 1:50 PM
jobtriggers/triggers.py
49

Yeah, but do we want to pull libtaskotron as dependency just so we can use TaskotronConfigError? I don't know how much code of libtaskotron will be needed in the trigger in future though. @tflink?

@ralph, your point makes sense to me.

kparal added inline comments.Apr 4 2014, 1:56 PM
jobtriggers/triggers.py
49

Good point. Does taskotron-trigger make sense without having libtaskotron installed? Won't it call runtask eventually?

tflink added a comment.Apr 4 2014, 2:13 PM

Yeah, but do we want to pull libtaskotron as dependency just so we can use TaskotronConfigError? I don't know how much code of libtaskotron will be needed in the trigger in future though. @tflink?

I've thought about that myself and I don't really see a reason to depend on libtaskotron here unless we want to support some sort of local execution engine (ie, buildbot replacement). Even if we did that, we can add the dep later and avoid the linking for now.

Good point. Does taskotron-trigger make sense without having libtaskotron installed? Won't it call runtask eventually?

In a very roundabout way, sure. It sends data to buildbot which schedules a job which eventually calls runtask. However, that's far enough removed that I don't think it makes sense for trigger to depend on libtaskotron right now.

mkrizek updated this revision.Apr 7 2014, 9:05 AM

Raise KeyError when trigger does not exist

ralph accepted this revision.Apr 7 2014, 1:17 PM
tflink added a comment.Apr 8 2014, 2:45 PM

Looks good to me

mkrizek closed this revision.Apr 8 2014, 2:55 PM

Closed by commit rTRGR7f83c79a41ad (authored by @mkrizek).