Use a deep copy when storing raw node data

[psss]

When the adjust() method is used it can modify data referenced
from the raw data dictionaries. Make a deep copy to ensure the
original data are preserved.

• add test coverage

[jscotka]

Hi, seems well.
I've also met this issue, but though that issue is on my side with regerated data from python decorators.
yep, seems like adjust() causes it. BTW, would not be better to fix adjust method if it somehow modify something what it should not modify? e.g. there can be found another issue with method use parameter and reference and potential future problem. and also reason why I've added lines for adjust to test https://github.com/psss/fmf/blob/master/tests/unit/test_modify.py#L82 :-) to prove that it does not modify adjust rule.

[psss]

It could be fixed on the adjust() side as well. However, when applying adjustments the adjust attribute is (intentionally) removed. So it is kind-of expected that adjust() modifies the data. Now the question is: Was it a good idea to remove the adjust content after the adjustments are applied? The motivation was: Data can be adjusted just once so let's remove the rules so that possible repeated application does not cause any unexpected/unpredictable changes. Shall we rather keep the rules there? This would also allow tmt test show to more easily show the adjust rules. Thoughts?

[psss]

/packit test

[lukaszachy]

I believe it would be better to allow repetitive adjust calls - tmt object stays "adjusted" until next adjust call.
AFAIK Alex and I need to remember tmt state before adjust (copy method) as our tooling need to call adjust multiple times.
Edit: So having support for multiple adjust right in the fmf/tmt would be very nice.

[jscotka]

my feeling is that it should be keep. I can imagine that in pipeline some additional step may change adjust output, e.g. some artificial example :-) I can have centOS and will use RH tool for converting centos to RHEL, and then adjust have to match that it is not centos but rhel (e.g. in prepare phase). I understand that it is little bit artificial, but way, that multiple call of adjustment is not bad. but feature. from py PoV.

And as Lukas mentioned. We need the up to date data, not changed, TMT adjust objects stores the data as well so that removing inside FMF is unnecessary and maybe much more dangerous.

[psss]

Makes sense. Let's allow repeated adjust() calls then. Will update the code.

[jscotka]

@psss @lukaszachy maybe as quick fix we can also use this patch and create new one (or issue) for your mentioned solution in adjust. Because it will be then also feature not just bugfix.

[lukaszachy]

I've added test, @psss please review.

[psss]

Thanks, @lukaszachy. The test looks good. Added changes needed to keep the original adjust rules intact, including a simple test.

[psss]

/packit test

[lukaszachy]

Hm, so integration fails on f34 as tmt changed 'enabled\s+yes' to true

[psss]

Yeap, another motivation to find an elegant solution for teemtee/tmt/issues/585 as soon as possible.