This has been discussed with @tkopecek who agreed to own this review.

@lsedlar, also CCing you here. Once this gets reviewed, I will add support for this new Koji task to Pungi.

It should be less, it is effectively not blocking anything and immediately spawns runroot. You can set it to 0.1

Is there any lorax argument needed by default? If not, lower it to 2. If yes, mark it properly in "usage"

permission should be checked here

    if not session.hasPerm('admin') or session.hasPerm('pungi_buildinstall'):
        parser.error(_("This action requires pungi_buildinstall or admin privileges"))

unused

unused

unused

This syntax is now working on py26 (use set() instead)

Thanks for the review. I will be AFK for the rest of this week. I'm going to address your comments on Monday.

Also, please reference placeholder issue in commit message via line: "Fixes: https://pagure.io/koji/issue/1940"

@tkopecek, I've added more tests and also fixed the names of some Lorax args.

@tkopecek, I've tested the current code with my Pungi changes and it successfully generated all the deliverables. I think the plugin is working correctly for me now and I treat it as complete for now.

@julian8628 @mikem

might be in stderr?

is this a debug print?

No, this is actually similar to "koji runroot --task-id" - it prints the ID of the executed Koji task.

No, this is actually similar to "koji runroot --task-id" - it prints the ID of the executed Koji task.

ok, could you make it more readable like task ID: xxxx?

:thumbsup: for the code

No, this is actually similar to "koji runroot --task-id" - it prints the ID of the executed Koji task.

ok, could you make it more readable like task ID: xxxx?

I could, but I wanted to keep this output compatible with the koji runroot output if possible. It saves some code in the Pungi. But of course I can change it if you still think so.

No, this is actually similar to "koji runroot --task-id" - it prints the ID of the executed Koji task.
ok, could you make it more readable like task ID: xxxx?

I could, but I wanted to keep this output compatible with the koji runroot output if possible. It saves some code in the Pungi. But of course I can change it if you still think so.

OK, that makes sense

How difficult would it be to make sure the permissions and owner is always updated, no matter whether lorax succeeded or failed?
Currently if lorax fails but manages to create some files already, the user who spawned the task will quite likely not be able to delete the files. (This is an issue with the existing implementation in Pungi. We didn't fix it since it's rather tricky to escape such a command line to pass to runroot.)

@lsedlar, that's good point. I will see what I can do to improve that.

We're going to bundle it only internally. Fedora seems to not use it in near future. If it will, we will bring it back to koji.