reworking runner and action handling to be more useful, output still has issues, will be fixed in another review - this one is large enough as it is
Details
tested locally with rpmlint (will update that repo shortly), added unit tests and all are passing
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
task-rpmlint on bitbucket has been updated for these changes. I wanted to push those changes to a non-master branch but that didn't work. We're not using that repo for running anything ATM so I'm just going to leave it as-is for now.
Looks good to me overall, just a few nitpicks.
libtaskotron/directives/dummy_directive.py | ||
---|---|---|
9 | Do you think it would be useful to list required input_data's keys for each directive in its class in pydoc? | |
libtaskotron/directives/koji_directive.py | ||
103 | Shouldn't this line be: "if 'envr' and 'arch' in input_data:"? | |
libtaskotron/directives/python_directive.py | ||
91 | file=<python file> | |
103 | Again, should we check for 'callable' and 'file' if they are present in input_data? | |
libtaskotron/runner.py | ||
5 | jinja2 is not included in requirements.txt | |
51–53 | I wonder, should we use term 'subtask' instead of 'action'? It might be a little confusing to use 'action' since not all directives have 'action' (the python directive) and if I am correct this is not action as in arg of a directive but action as in subtask, right? | |
readme.rst | ||
32 ↗ | (On Diff #12) | This change is already in develop. |
Thanks for the comments, I'll get the stuff changed
libtaskotron/directives/dummy_directive.py | ||
---|---|---|
9 | yeah, I'll add that for the two directives | |
libtaskotron/directives/koji_directive.py | ||
103 | yeah, there should be some input validation here and in all the directives | |
libtaskotron/runner.py | ||
51–53 | I'd prefer changing the parameter name for koji if there's potential for confusion. To me, the idea of a task made up of actions flows well in a linguistic sense while the directive arg could be changed from 'action' to 'command' without any loss in how natural it sounds. |
libtaskotron/runner.py | ||
---|---|---|
51–53 | That works for me. |
- Fixed documentation, input arg checking and requirements.txt from comments in review
I'm not sure why the readme.rst changes still show up here - there is no difference between the branches on my local system. Either way, I'll make sure that the file doesn't change when I merge to develop
libtaskotron/runner.py | ||
---|---|---|
79 | Why don't we run the yaml file through jinja first and then load it so we do jinja parsing just once. Is there a reason we do jinja parsing for each action separately? Unless I am missing something. |
That was the best solution that I came up with, anyways. I'm open to other suggestions, though
libtaskotron/runner.py | ||
---|---|---|
79 | because not all the variables exist when the yaml file is loaded. The biggest example of this is for values which are exported - the actual values don't exist until after the action has been run. If we render the template before that execution, the value will be empty (at best) and the data won't be transferred between actions |
libtaskotron/directives/koji_directive.py | ||
---|---|---|
98 | It would be much better to use some custom Exception - maybe some libtaskotron-wide but libtaskotron specific one | |
libtaskotron/directives/python_directive.py | ||
100 | It would be much better to use some custom Exception - maybe some libtaskotron-wide but libtaskotron specific one |
jskladan - yeah, error handling is something that needs to be improved and made consistent throughout the codebase. Just raising bare Exceptions isn't the best solution but I'd rather handle that in a different ticket/patch. This one's big enough as it is.
Do you think it would be useful to list required input_data's keys for each directive in its class in pydoc?