add additional properties to copr messaging schema

[ryanlerch]

the COPR fedora-messaging schema needs a handful of additional properties added to make the messages work perfectly with the upcoming release of the new FMN. These are:

• agent_name: https://fedora-messaging.readthedocs.io/en/stable/api.html#fedora_messaging.message.Message.agent_name so this would be the name of the person that started the action (e.g. build)
• usernames: https://fedora-messaging.readthedocs.io/en/stable/api.html#fedora_messaging.message.Message.usernames
• groups: https://fedora-messaging.readthedocs.io/en/stable/api.html#fedora_messaging.message.Message.groups
• app_name: https://fedora-messaging.readthedocs.io/en/stable/api.html#fedora_messaging.message.Message.app_name

FMN also needs artifacts properties ( packages , flatpacks, containers, and modules ) but these are typically only to relate to Fedora "artifacts" -- i.e. something tracked in src.fp.o, so i dont think we need these in COPR

Note that FMN also needs the summary and str properties, but these already appear to be implemented in the copr schemas

[FrostyX]

Thank you @ryanlerch, we will take a look into that. I appreciate the documentation links.

[ryanlerch]

Thank you @ryanlerch, we will take a look into that. I appreciate the documentation links.

i'm working on the app_name one now, FWIW -- a PR should be in soon

the others are a little more difficult for me without knowing heaps about COPR internals

[ryanlerch]

also, if it helps, we have couple other PRs in flight on other apps that implement some of these:

• https://github.com/fedora-infra/anitya-messages/pull/53
• https://github.com/fedora-infra/bodhi/pull/4951
• https://github.com/fedora-infra/noggin-messages/pull/290
• https://pagure.io/elections-messages/pull-request/1

[praiskup]

Thank you for the report Ryan!

the COPR fedora-messaging schema needs a handful of additional properties added to make the messages work perfectly with the upcoming release of the new FMN. These are:

Is this already alive, or how much time do we have before the new FMN is deployed?

• agent_name so this would be the name of the person that started the action (e.g. build)

According to the specs, it seems None is an acceptable field value. Is that "correct" from the Fedora policy perspective? We don't always know who submitted the build if it was done via a http webhook (a private per-project token is needed to submit build like that, so we could blame the project somehow ...). Or do we have to name a concrete FAS user?

• usernames
• groups

Not sure about this. If build is done, the package is shipped to users who we don't know. What is the expected value?

FMN also needs artifacts properties ( packages , flatpacks, containers, and modules) but these are typically only to relate to Fedora "artifacts" -- i.e. something tracked in src.fp.o, so i dont think we need these in COPR

I think we can fill at lest packages. Though naturally they might not exist in src.f.o, would that be a problem?

[ryanlerch]

Thank you for the report Ryan!

the COPR fedora-messaging schema needs a handful of additional properties added to make the messages work perfectly with the upcoming release of the new FMN. These are:

Is this already alive, or how much time do we have before the new FMN is deployed?

a development version of the new FMN is currently running in staging, and we are looking to have it deployed to prod next month. Note however that it really is an entirely new system -- so there is no migration of notification rules from the old to the new system.

If the properties aren't implemented in the schema, it won't "break" FMN as such, but a user wont get a notification from COPR if they have set up to be notified for actions started by a specific username (i.e. the agent_name)

• agent_name so this would be the name of the person that started the action (e.g. build)

According to the specs, it seems None is an acceptable field value. Is that "correct" from the Fedora policy perspective? We don't always know who submitted the build if it was done via a http webhook (a private per-project token is needed to submit build like that, so we could blame the project somehow ...). Or do we have to name a concrete FAS user?

Yeah, None is acceptable, but a user obviously wont get that notification because it wont match the filter they may have created

• usernames
• groups

Not sure about this. If build is done, the package is shipped to users who we don't know. What is the expected value?

The usernames lists are supposed to be all the usernames that are affected by the message. One example could be if you have two users with permissions on a COPR repo -- one user kicks off the build, so they are the "agent_name", and everyone that has permissions or follows or whatever that repo are "affected" by that message, so they are all listed in the usernames list. (this is really up to the apps discretion here) -- some apps the usernames list is just a single item list with the agent_name -- since no other users are affected.

Same concept for the groups list -- but obviously for groups.

FMN also needs artifacts properties ( packages , flatpacks, containers, and modules) but these are typically only to relate to Fedora "artifacts" -- i.e. something tracked in src.fp.o, so i dont think we need these in COPR

I think we can fill at lest packages. Though naturally they might not exist in src.f.o, would that be a problem?

Not really a problem -- however on the FMN side, we only let users filter this field based on the list from src.fp.o -- so if yopu fill out packages, and that package exists in src.fp.o it'll match otherwise it will likely never match.

[praiskup]

Triage time: Let's take a look once more on this ticket, and decide what to do next on Copr side.

[praiskup]

Seems like #3099 is tightly related.