Add rpm_to_build() method to koji_utils
ClosedPublic

Authored by jskladan on Jun 23 2014, 10:25 AM.

Details

Summary

This method is required for depcheck's squashing of per-rpm results
to per-update results.
It takes a rpm filename on input and returns build info from koji.
It has "caching/prefetching" capabilities to speed-up subsequent queries.

Test Plan

Tested with Depcheck several times

Diff Detail

Repository
rLTRN libtaskotron
Lint
Lint Skipped
Unit
Unit Tests Skipped
jskladan retitled this revision from to Add rpm_to_build() method to koji_utils.Jun 23 2014, 10:25 AM
jskladan updated this object.
jskladan edited the test plan for this revision. (Show Details)
jskladan added reviewers: tflink, kparal.
jskladan added subscribers: mkrizek, pschindl.
tflink requested changes to this revision.Jun 23 2014, 11:37 AM

I'd like to see some unit test coverage for the new method but the concept seems sound.

This revision now requires changes to proceed.Jun 23 2014, 11:37 AM
jskladan updated this revision to Diff 431.Jun 23 2014, 12:13 PM
  • added tests
tflink accepted this revision.Jun 23 2014, 12:18 PM

Looks good to me

This revision is now accepted and ready to land.Jun 23 2014, 12:18 PM
jskladan closed this revision.Jun 23 2014, 12:48 PM
jskladan updated this revision to Diff 436.

Closed by commit rLTRNb420fe644aea (authored by @jskladan).

Too late, already pushed. But here are my comments.

libtaskotron/koji_utils.py
36

Please document what this is for and how does it look inside. It's very unpleasant if one has to find that out from reading the code scattered around. Either use:

# comment
self._rpm_to_build_cache = {}

or

self._rpm_to_build_cache = {}
''' a docstring '''
38

I understand the reasoning behind prefetch, but I'm a bit concerned whether it is helpful enough. RPM searches in Koji take a long time. If there are several dozens of builds to run through depcheck, it will take a really long time, no matter buildinfo caching.

I think this should rather take a list of rpm filenames as an input, and then make all the queries at once using Koji's multiCall. I imagine this will be at least 10x faster for larger sets of RPMs. You can have a look at upgradepath and see how multicall is used.

I don't say it has to be implemented right now, but I think it would be highly preferable. If you decide to stay with current implementation because of time constraints, please at least file a ticket?

41

Use need to use double backticks, if you're trying to highlight the text as code/value.

45

Return type is documented, but return value is not. Let's say something like:

:return: Koji buildinfo dictionary (as returned e.g. from :meth:`koji.getBuild`)
45
:rtype: :class:`bunch.Bunch`
46

I was a bit confused by the phrase "or build", because I don't specify "build" anywhere. Let's use "or its build", "or its related build" or something along the lines.

48

Something like # strip path would help a bit for those of us who don't know the whole Python library by heart ;)

jskladan added inline comments.Jun 23 2014, 1:10 PM
libtaskotron/koji_utils.py
36

Ooint taken, although I do not really see the need to document its contents as this is to be used only in the one piece of code, and the variable is marked as "private". But I guess there will be no harm in it.

38

I can file the ticket, although from what I tried, this helps quite a lot.

41

thx

46

Thx, I'll be your SPHINX padawan soon enough :)

48

*shrugs* OK, I can comment on that line, although # grab filename from path says more about the intent, I guess

Resolved in D152.