drop 'name_cb', make uniqueres magic values more flexible
ClosedPublic

Authored by adamwill on Dec 18 2015, 2:16 AM.

Details

Summary

So we kinda have two different ways of doing the same thing,
here; in the TESTCASES dicts, both the 'name_cb' callback
function mechanism and the magic $FOO$ values ultimately result
in the value being taken from the openQA job settings somehow.
We only have the one callback, but we have lots of $FOO$ values,
so let's standardize on that approach and clean it up a bit.
The $FOO$ values will now be replaced in *any* of the dict
values (not just env), and the implementation is rather cleaner,
it's split into a separate function.

Test Plan

Run a full result generation and check all ResTuples
are correct (should be unchanged from previous commit).

Diff Detail

Repository
rOPENQA fedora_openqa
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
adamwill retitled this revision from to drop 'name_cb', make uniqueres magic values more flexible.Dec 18 2015, 2:16 AM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)
adamwill added reviewers: jskladan, garretraziel.
garretraziel requested changes to this revision.Dec 18 2015, 12:02 PM

Looks good overall (and it's definitely better that we will have this ugly hardcoded magic in one place). I have only small tidbit - in my opinion, the real Pythonesque way is to create new dictionary with replaced values in _uniqueres_replacements function. Then you just do uniqueres = _uniqueres_replacements(job, uniqueres).

This revision now requires changes to proceed.Dec 18 2015, 12:02 PM
adamwill added a comment.EditedDec 18 2015, 1:28 PM

Why would that be better? Then we have two dictionaries lying around but we're not using the first for anything. Since we're never interested in the original values any more, just changing them in-place in the same dict seemed more elegant to me, it was intentional. I didn't split it into a function because I expect us to reuse that logic at any point, but simply for clarity...

garretraziel accepted this revision.EditedDec 18 2015, 1:50 PM

OK, after some consideration, while "not-modifying lists and dicts inplace" is pattern I follow, there is no written best-practice for Python that says that, so feel free leaving it as it is.

This revision is now accepted and ready to land.Dec 18 2015, 1:50 PM
This revision was automatically updated to reflect the committed changes.