#9510 Collaborators should be allowed to create update in bodhi
Opened 4 months ago by pingou. Modified 7 hours ago

People with a "collaborator" level access on pagure should be allowed to create new updates in bodhi.

Ideally, they should only be allowed to create updates for the releases corresponding to the branches they have access to. In practice, I wonder if we shouldn't simplify it and let them create any update.
In the current world, they would only be able to create update they built or someone else (who was allowed to bump the evr) built.
With rpmautospec this would change as one could do a build without committing to the git repo.
On the other hand, with stream branching the mapping from git branches to dist-tag/fedora releases gets potentially impossible to do.

Considering we have tracking of who does what, I prefer the simpler approach of considering (in bodhi) people with a contributor level access to have the same access as committers.


Metadata Update from @pingou:
- Issue tagged with: dev

4 months ago

Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: bodhi, medium-gain, medium-trouble

4 months ago

For classic RPM updates it should be not too hard to modify actual ACL verification mechanism to allow collaborators to push updates only on those branches they are allowed to commit. We already have a "bodhi release to pagure branch" mapping in Bodhi, but we would probably need to replicate how pagure reads the pattern for collaborators access.
For modules, since there's no direct mapping between branches name and releases, this would be impossible, I think. Not sure about flatpaks and containers, I don't know very well how things work for those.

We could also change the Bodhi validation mechanism to use another approach. Currently, when submitting a build, Bodhi retrieves the list of admins and committers for the package from Pagure, then it checks for the update submitter username to be in those lists (or for the group of the submitter to be in one of the group list with commit access).
A simpler approach, supposing there's an appropriate API in Pagure to do that, would be making Bodhi query Pagure if a username has the necessary rights on a package+branch, so that we rely on Pagure validation directly.

That should be ok to merge (although we need a new release of bodhi and to deploy it)

SO it looks like https://github.com/fedora-infra/bodhi/pull/4181 is now merged. Bodhi just needs to do a new release now.

Metadata Update from @ryanlerch:
- Issue assigned to ryanlerch

12 days ago

I'll have a go at spinning up a release on the bodhi side. The docs there seem pretty comphensive on how to go about this.

I'll have a go at spinning up a release on the bodhi side. The docs there seem pretty comphensive on how to go about this.

Note that the commit that made the release notes of 5.6.1 was not pushed on devel branch, so you might need to adjust those. See https://github.com/fedora-infra/bodhi/pull/4197 for reference.
(I've retired that PR because I would like to have https://github.com/fedora-infra/bodhi/pull/4200 merged in the new release)

@mattia sorry! didnt realise you already started cutting a release.

with the freeze around, we probably wont get this deployed in prod for a bit anyway i suppose, so wait til fedora-infra/bodhi#4200 is merged, then cut a release maybe?

Metadata Update from @ryanlerch:
- Assignee reset

10 days ago

Bodhi 5.7.0 is now deployed in staging.

Metadata Update from @ryanlerch:
- Issue assigned to ryanlerch

7 hours ago

Login to comment on this ticket.

Metadata
Boards 1
dev Status: Triaged