packit
Listen to copr `request-permission` and grant admin/builder privilege to packager
Description
I occasionally find myself needing to delete older copr build in a packit generated project. Would be nice if packit could listen to a request-permission (probably different event name) and grant builder/admin to the linked project packager.
Not sure if admin can grant further admin privilege, or if packit would need to manage those as well.
What is the impacted category (job)?
Copr builds, General
Workaround
- [ ] There is an existing workaround that can be used until this feature is implemented.
Participation
- [ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)
HIi@LecrisUT !
We've quickly discussed this within a team and it's not so simple:
- We need to be careful to not give the permission to someone else.
- It can cause Packit issues if someone tries to change something => I would try to avoid giving admin rights to anyone. (Or make it really sure this can cause problems.)
- A few situations where this was needed was only a workaround for another issue => would be nice to know in what situation you need this and we might be able to fix the core issue. E.g. DNF5 (as a part of buildroot) found that builds are affecting each other and the proper solution is to use
bootstrap_imageoption. - Also, there is a slight difference between temporary and stable projects I would say.
- For stable ones, one can either use its own project and give Packit permissions or, ask as to give the permissions manually (counting the number of requests, this is fine).
- For temporary ones, one can, as a workaround, recreate the pull-request to get a new project. Otherwise, this needs to be automated.
So, since this would require untrivial work to do right and we can give the permissions manually, I would go with the manual requests for now and if we realise there is a high number of requests, we can think about a proper solution.
What do you think? Do you have any simple solution in mind we can use to reliably+safely provide this to the correct users?
For the case where I needed it, it was because I was:
- working on a package review chain, so I need the NVR to be as in the spec file in order to download the srpm later
- did some changes without bumping NVR (since there is no
%autoreleasesupport in copr), but when there is another build depending on the package, a random copr build with the same NVR is chosen instead of the latest build - proper solution would be to build in specific project, but often I don't want to create an individual one, since the review could be very simple
What do you think? Do you have any simple solution in mind we can use to reliably+safely provide this to the correct users?
There is already ACL between github user and github project, where it checks that the Fedora user has the Github user exposed. What about hooking in the same checks, where we go from Fedora user -> Github user and if the Github user is authorized in the project, then grant admin permissions (if requested)?
@LecrisUT finally getting back to this. Since you mentioned package_review, I have been thinking for some time about having a dedicated project (with Packit setup) for exactly this purpose. The review can happen in the form of a pull request (with CI (build+checks) and human suggestions. I finally need to prepare a prototype of this.
There is already ACL between github user and github project, where it checks that the Fedora user has the Github user exposed. What about hooking in the same checks, where we go from Fedora user -> Github user and if the Github user is authorized in the project, then grant admin permissions (if requested)?
Yes, sounds valid. I am putting it into the backlog and wait if others would be interested in this.