This doesn't make a streaming log, does it?

No, it would need more work (#3600)

:thumbsup:

Updated to streaming log. @mikem can you check added mock option?

This should also fix it being captured for scratch builds too, right? (Right now, that doesn't happen regardless of success or failure)

Cf. https://cbs.centos.org/koji/taskinfo?taskID=3105781

yes, works for scratch builds also

code lgtm :thumbsup:

@ignatenkobrain, can you test this in your koji deployment?

Wait a bit until @mikem checks on this. I'm not happiest about mock change here.

It seems weird for this option to accept absolute paths. I'd expect any paths specified to be relative to the rootdir.

It looks like the log_timestamps feature will not function for these logs.

Would it make sense to provide additional directories to watch for logs, rather than individual files? If so, I think this might simplify implementation quite a bit.

1) makes sense
2) depends of 3
3) It makes sense but doesn't allow renaming of logs. It is similar to ozlog handling, we need to add arch there to not conflict with other subtasks. Maybe just extend ts handling to put -ts.logs to the same directory as original log instead of resultdir?

You can set the logfile to go somewhere else with the --logfile global option.

The default from kiwi for kiwi system build is that if --logfile isn't passed, it'll write it to that path: https://github.com/OSInside/kiwi/blob/698398cca03f8bf99f26b38a57312b3d430a7022/kiwi/tasks/system_build.py#L142-L145

So you can do kiwi-ng --logfile=/path/to/somewhere/kiwi-system-build-{arch}.log system build to redirect it.

You probably also want a log file for the kiwi-ng result bundle too, like so: kiwi-ng --logfile=/path/to/somewhere/kiwi-result-bundle-{arch}.log result bundle.

You can also tell kiwi to use an existing Unix domain socket listening for input if you want by using --logsocket instead of --logfile if it helps.

Nice, much easier - missed that somehow.

Anyway, we need to "copy" them outside of chroot. So, I've created symlink from resultdir to chroot/tmp. It works "sufficiently" (few error messages in between symlink creation and target file creation)

Missing f prefix here.

String quoting inconsistency here.

lgtm

:thumbsup:

Commit 1802b9f3 fixes this pull-request