Make YAML variables and CLI arguments naming consistent
ClosedPublic

Authored by mkrizek on May 28 2014, 11:57 AM.

Details

Summary

Once accepted, I will amend all checks' yaml files accordingly.

Fixes T180

I believe this fixes T129 as well.

Test Plan

Run any check (do not forget to amend its yaml file) and/or test suite.

Diff Detail

Repository
rLTRN libtaskotron
Lint
Lint Skipped
Unit
Unit Tests Skipped
mkrizek retitled this revision from to Make YAML variables and CLI arguments naming consistent.May 28 2014, 11:57 AM
mkrizek updated this object.
mkrizek edited the test plan for this revision. (Show Details)
mkrizek added reviewers: tflink, kparal, jskladan.
mkrizek updated this revision to Diff 311.May 28 2014, 12:07 PM

Update taskyaml docs as well

kparal requested changes to this revision.May 28 2014, 12:27 PM

It seems OK, thanks. Just a few documentation requests.

docs/source/taskyaml.rst
57–61

Could you please add a short example for each of these args? So that people know what format is expected (koji_build has two, bodhi_id has two, arch can be a list perhaps?). Thanks.

libtaskotron/directives/koji_directive.py
19

Maybe this could say:

"koji: command=download koji_build=<N(E)VR to download> arch=<desired arch>

in order to be more obvious.

69–72

If we are to stick to the terminology, this should probably say:

"Getting RPMs for %s (%s) and downloading to %s"

libtaskotron/runner.py
16

If this should be a public variable, it should have a docstring below it, so that it appears in our generated docs.

If this should be a private variable, it should start with an underscore... and it should have a docstring below/comment above it, so that it's clear what it is used for. Something like

The list of accepted item types on the command line (--type option)

This revision now requires changes to proceed.May 28 2014, 12:27 PM

Looks pretty good to me other than the things kamil mentioned

libtaskotron/directives/koji_directive.py
69–72

I'm not sure I understand the advantage of that phrasing. It is downloading a koji build which is a set of 1 or more rpms, no?

kparal added inline comments.May 28 2014, 1:26 PM
libtaskotron/directives/koji_directive.py
69–72

Yes, therefore "getting koji builds for <koji build>" seems weird. A build consists of RPMs, so you can get rpms for a koji build. Or you can get koji builds for a koji tag. But you can't get koji builds for a koji build. Or am I missing something? :)

tflink added inline comments.May 28 2014, 1:37 PM
libtaskotron/directives/koji_directive.py
69–72

OK, I see what you're getting at. How about

"Getting RPMs for koji build %s (%s) and downloading to %s"

I'd prefer that it be specific on what it's downloading since an nevr can be a little ambiguous.

kparal added inline comments.May 28 2014, 2:24 PM
libtaskotron/directives/koji_directive.py
69–72

Sure, great! :)

mkrizek updated this revision to Diff 312.May 28 2014, 3:12 PM

Address comments mentioned in the review

tflink accepted this revision.May 28 2014, 4:09 PM

Looks good to me

mkrizek closed this revision.May 29 2014, 8:11 AM
mkrizek updated this revision to Diff 318.

Closed by commit rLTRN45d1013b3694 (authored by @mkrizek).