Add test for log processing

[elkoniu]

'/usr/libexec/anaconda/log-capture' is an util to generate runtime logs. This commit adds test validating output of this util.

[M4rtinK]

Looks good to me - thanks! :)

Just added some suggestions for using fragments to provide generic/boilerplate bits in the kickstart via kickstart fragments. :)

[elkoniu]

@M4rtinK thanks for the review. I have updated the code following your guidelines. Also I have split test cases in half: check if the util exists, call the util and expect 0 return code. Do you thing this is good enough validation?

[KKoukiou]

/test-tmt

[KKoukiou]

/test-os-variants

[M4rtinK]

@M4rtinK thanks for the review. I have updated the code following your guidelines. Also I have split test cases in half: check if the util exists, call the util and expect 0 return code. Do you thing this is good enough validation?

Agreed with the split - like this we can easily see from the logs what exactly went wrong, nice! :)

As for validation - it creates a tarball, right ? I guess we could check the file exists and is of non-zero size ? But I leave it up to you, given we already check the return code. :)

[elkoniu]

@M4rtinK @KKoukiou I think this PR is in final shape now and it is passing when I trigger it locally.

[rvykydal]

Nice work.

We should perhaps clear up the TESTTYPE though (as suggested above)

Also I wouldn't create an include (lib) script at this point where the functions are used only in a single test. But if we create it I'd keep a (silent) convention of having -lib- in the name, ideally with post and nochroot hint. But this can be done updated / discussed in a followup PR. Having more tests using the shared script would also make easier to decide where to put the functions or how to name a new file if we create such.

[elkoniu]

Thanks for the review @rvykydal
I just pushed the latest version and tried to address all of your comments

Nice work.

We should perhaps clear up the TESTTYPE though (as suggested above)

Also I wouldn't create an include (lib) script at this point where the functions are used only in a single test. But if we create it I'd keep a (silent) convention of having -lib- in the name, ideally with post and nochroot hint. But this can be done updated / discussed in a followup PR. Having more tests using the shared script would also make easier to decide where to put the functions or how to name a new file if we create such.

I like this idea. On my todo list there is a small refactoring of the repo (which includes making default repo README more visible). I would like to address this '-lib-' idea as a part of this refactoring.

[rvykydal]

/test-os-variants

[rvykydal]

/test-tmt

[rvykydal]

Looks good to me, thank you.