Allow Bodhi update to be created for builds triggered by any configured user

[praiskup]

Description

We have configured the bodhi_update job (together with commit and pull_from_upstream):
https://src.fedoraproject.org/rpms/resalloc-ibm-cloud/blob/rawhide/f/packit.yaml

I noticed that the last release (with Tito) did not trigger bodhi_update, and that's (probably)
because Packit is not the commit author, nor build submitter (I did that).

The thing is that all of this is wrapped by tito release, which itself (a) commits to Fedora git,
(b) uploads tarball into dist-git and (c) submits the Koji build (all under my name).

Typical Tito user workflow is:

1. tito tag // produces new release
2. git push --tags
3. tito release // e.g. tito release fedora-all
4. fedpkg update // a single command to generate N updates for each fedora
5. create a release in GH -- upload tito tarball into GitHub

It is somewhat weird to stop doing step 3, and re-shuffle the old-school release work-flows.

The step 4. is though relatively inconvenient task (I need to know the NVRs) and totally async. Worth doing automatically.
Can't we again allow-list a list of FAS users that, when they submit a build, automatically create a bodhi update via packit?

Benefit

A native Tito user feeling during the release-to-Fedora scenario.

Importance

I'm not yet sure, I just promised to fill this issue. I have to get more familiar with pull-from-upstream to judge; if we can make Packit create multiple PRs (multiple fedora brnaches) with the same commit hash (so all merge events result with the same final git-sha1).

What is the impacted category (job)?

Fedora release automation

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!)

[lbarcziova]

hi @praiskup, thanks for this RFE.

So the request is to make Packit react (=> create Bodhi updates) for Koji builds not submitted by Packit, but submitted by someone allowed by configuration, right?

We have touched on this topic a few times already so I think it is worth confirming with the team on arch (I noticed we have already this TODO in the code :D ). From the implementation side, this should be quite simple and should not be a problem, but we would need to listen to all messages about Koji build end and not filter the packit-submitted ones.

[lbarcziova]

@packit/the-packit-team regarding the naming of the config option for this, we already have allowed_pr_authors and allowed_committers that are checked for dist-git pushes, so I would go with something like

• allowed_(koji_)build_submitters
• allowed_(koji_)build_owners
• allowed_builders

WDYT? Feel free to comment other suggestions.

(EDIT: for context, Koji shows Built by for build, Owner for task and the fedmsg messages have this info as owner)

[mfocko]

Looking at the Koji webpage, it says built by, so I'm voting for allowed_builders to keep it as similar as possible.

[xsuchy]

I will add another one :) allowed_to_trigger_build - long, but descriptive.

[lbarcziova]

@xsuchy since this is actually about triggering Bodhi updates, I guess allowed_to_trigger_updates would probably make better sense, WDYT?

[lbarcziova]

thinking about it more, there are 2 ways of triggering a build:

1. successful Koji build
2. by /packit create-update comment

I initially understood this new configuration option should influence only the 1. and in that case, the allowed_to_trigger_updates might be confusing

OR we could consider this option for both ways of triggering and in that case this name would make sense - but this would be IMO again inconsistent with how we have it for koji builds

[praiskup]

I was very confused today, sorry. I don't mind that much. But since you asked my opinion, here are some suggestions:

{fedora|bodhi}_update_if_built_by = []
bodhi_if_built_by = []
bodhi_builders = [] # this would give it some attention :D