modify the libtaskotron code to support the change in task-rpmlint
AbandonedPublic

Authored by lnie on Jul 20 2016, 3:35 AM.

Details

Summary

modify the libtaskotron code to support the change in task-rpmlint

Test Plan

just run the normal rpmlint task with bodhi_id

Diff Detail

Repository
rLTRN libtaskotron
Branch
angel
Lint
Lint OK
Unit
Unit Test Errors
Build Status
Buildable 736
Build 736: arc lint + arc unit
lnie retitled this revision from to modify the libtaskotron code to support the change in task-rpmlint.Jul 20 2016, 3:35 AM
lnie updated this object.
lnie edited the test plan for this revision. (Show Details)
lnie added reviewers: jskladan, kparal, lbrabec.
jskladan added a comment.EditedJul 20 2016, 6:04 AM

Some comments on the code, as I think the implementation deserves some comments since you are learning, and plain "no" would not be helpful. That said, I am absolutely unconvinced that this whole idea is sound, or has merit. I don't see any actual advantage, and have not been shown one so far, nor does this fix any reported issue.

libtaskotron/directives/koji_directive.py
59–222

It does not make sense to change the parameter name in the koji directive, it is not semantic, and suggests other behaviour than what is implemented (seems like you could download koji build based on bodhi update id, but that is not true. It also does not need to be changed in respect to the rpmlint patch, you could just put a different variable (koji_bodhi in your case) as a value to the koji_build (or update_id in the bodhi directive case) without changing the actual parameter name.

libtaskotron/executor.py
137–143

Absolutely not - you can not just silently "do nothing" without even a warning log message. If you wanted to do this, then this is not event the right place - it should be in the respective directive code, and not "automatic" - there should be an option in that directives (something like dont_fail, set to Falseby default), that can be overriden in that one specific case, where you don't want the directive to just plain fail. It would also not be driven by the item_type at all, it would just make sure that when an update/build is not found, the directive won't fail. Which in itself has problems, and I'd argue against the whole concept of it.

libtaskotron/main.py
112

If you wanted to do what this seems to want to do, then you should explicitly check whether args['type'] is in [KOJI_BUILD, BODHI_UPDATE], and populate the koji_bodhi only then.

jskladan requested changes to this revision.EditedJul 20 2016, 6:06 AM

double post

This revision now requires changes to proceed.Jul 20 2016, 6:06 AM

Also - before you post a patch for review, you should make sure that all unittests are passing. This amount of failed tests is a reason to nack the revision on its own, without further review.

lnie added inline comments.Jul 20 2016, 8:33 AM
libtaskotron/directives/koji_directive.py
59–222

I see what you are talking about,but I was just wanting to take full advantage of task-rpmlint,and add a bodhi_id support for rpmlint.

libtaskotron/executor.py
137–143

Maybe we can just close this diff ,if it will takes so much time and need so complex change.

libtaskotron/main.py
112

Good suggestion: )

I assume this is tightly related to D939 (next time, you can use Edit dependencies to link the tickets together -- I just did it now; or at least mention it in the description). If that's the case, I think we can do the same as for D939 - choose Abandon revision. If I understood it correctly, this is not something that we want in libtaskotron right now.

lnie added a comment.Jul 22 2016, 7:05 AM
In D942#17762, @kparal wrote:

I assume this is tightly related to D939 (next time, you can use Edit dependencies to link the tickets together -- I just did it now; or at least mention it in the description).

yes,and thanks for doing that.Actually,I added it ,but I removed it later,cause it reminded me of the dead lock:D939 can't be closed until D942 is closed,vice versa(now I know I have thought too much^^),and considering people can see my 'add and remove' action history,I thought it's fine to leave it alone.

lnie abandoned this revision.Jul 22 2016, 7:05 AM