Allow dynamic Copr projects in a custom namespace/group

[nforro]

Currently, it is possible to configure a static custom Copr project using owner and project options, but it would be nice to allow to set only owner and have projects created dynamically just like Packit does by default, only in that namespace/group.

Setting owner and not project now leads to no jobs being triggered because of an unhandled CoprNoResultException in CoprBuildJobHelper.is_forge_project_allowed_to_build_in_copr(): https://github.com/packit/packit-service/blob/d95578f528b9aa8c8d40c97c87dae66ea92276e0/packit_service/worker/helpers/build/copr_build.py#L342-L344

[pbrezina]

Hi, I think this is not entirely a must have but it would be very nice. Instead of packit/authselect-authselect-$pr_id we could have @authselect/pr$id that we use currently, it's shorter, more logical (authselect is there only once) and easier to remember.

[lachmanfrantisek]

I am wondering if we should just do the same as Packit and/or allow people to template this (as @pbrezina suggests). Both make some sense and solve this. I would probably start with what Packit does and add templating if needed.

The main issue is if it's doable from the permission point of view -- we need to check with the Copr team if it's possible to create projects for another user. (Currently, Packit gets permission for a particular project.)

But I hope it's doable for groups.

[lachmanfrantisek]

Confirmed with Kuba from the Copr team..;( He has suggested a workaround to create a project as Packit and grant the user access.

And as I've checked the Copr UI, the groups come from FAS. @pbrezina would it help you to do this inside a FAS group (and add Packit there)?

Otherwise, I am worried there isn't much we can do here.

[pbrezina]

You mean adding packit user to the FAS group? I don't have a problem with it.

[lachmanfrantisek]

@pbrezina thanks for a quick response. That's probably the only option that could work. So, just to confirm. Would it still be valuable for you to specify the FAS group as an owner, make Packit a member and use the same naming schema as used for regular Packit-created projects, just in this group?

[pbrezina]

@pbrezina thanks for a quick response. That's probably the only option that could work. So, just to confirm. Would it still be valuable for you to specify the FAS group as an owner, make Packit a member and use the same naming schema as used for regular Packit-created projects, just in this group?

You mean it would be @authselect/authselect-authselect-$prid? No, that would be ridiculous :-)

[lachmanfrantisek]

OK, so we would need to implement templating as well then.

I am putting this to backlog for now. Let's see if there is anyone else interested in this but let us know, @pbrezina if this becomes urgent/crutial for you.

[pbrezina]

OK, so we would need to implement templating as well then.

I am putting this to backlog for now. Let's see if there is anyone else interested in this but let us know, @pbrezina if this becomes urgent/crutial for you.

Not urgent, and it is nothing that prevents me from going packit. We are using https://github.com/next-actions/copr that I developed for authselect and sssd that builds pull requests this way and imho it makes sense to implement the templating as a nicer way to organize things but I still see a benefit in using packit instead.

[lbarcziova]

Besides the issues mentioned in the previous comments, we would also need to think of a mechanism of allowlisting that the particular upstream repo can create the new Copr projects in a particular Copr namespace via Packit, which might not be an easy task (e.g. implement something like Packit allowed forge projects on namespace level).

#2539 could alternatively solve this, but we might still need to take the allowlisting aspect to consideration.

[lsm5]

podman workflow would find this desirable mainly because we'd like to have some of our coprs to exist beyond the usual 60 days allowed on default packit coprs.

[lbarcziova]

hi @lsm5 , we have just discussed with @nforro that this should be in the end possible with just setting the preserve_project: true in the configuration, sorry for the confusion. Would there be any other reason why you would benefit from implementation of this issue?

[lsm5]

hi @lsm5 , we have just discussed with @nforro that this should be in the end possible with just setting the preserve_project: true in the configuration, sorry for the confusion.

@lbarcziova @nforro could you confirm preserve_project: true works for packit prod as well? IIRC, I was told on matrix it only works for packit-stg. If it does work for prod, that's good enough for me.

[nforro]

Yes it does, sorry, my bad.