Please don't skip archiving these files.

:thumbsup:

@tkopecek what was the reason you did not want to archive those files in the beginning (initial kiwi support)?

It was just PoC "quickness" - there was no special reason. Btw, there is probably also remaining problem for multiarch builds as @djuarezg found when working on DUD plugin which needs to be fixed.

there was no special reason

Ok then, I've removed that skip condition.

remaining problem for multiarch builds as @djuarezg found when working on DUD plugin which needs to be fixed

Not sure about that one, but I guess I don't have to fix it right now in this PR :)

Dropped testing-ready tag, merge conflict in QE. I'll add testing-ready tag in future.

there was no special reason

Ok then, I've removed that skip condition.

remaining problem for multiarch builds as @djuarezg found when working on DUD plugin which needs to be fixed

Not sure about that one, but I guess I don't have to fix it right now in this PR :)

For context, this is the root cause that appears on the multiarch kiwi builds that @tkopecek mentioned and on my plugin, based on yours:

As soon as you initialize the BuildRoot it autocreates the hw_info.log, root.log, state.log etc and when child tasks are done it tries to put them into a path such as /koji/packages/myamazingthing/12/1/data/logs/image/. This then causes a failure as both child tasks (running both x86_64 and aarch64 builds) are trying to put their result logs into the same path, raising:

GenericError: Traceback (most recent call last):
  File "/usr/share/koji-hub/kojihub.py", line 10279, in importImageInternal
    raise koji.GenericError("Error importing build log. %s already exists." % final_path)
koji.GenericError: Error importing build log. /koji/packages/myamazingthing/12/1/data/logs/image/hw_info.log already exists.

I did not find any issue or PR for this, so if it exists please point me out to it.

@djuarezg I've created #3210 for that.

closing as related commits are already part of #3205