On Thursday, July 9, 2020 4:51:29 PM CEST Tomas Tomecek wrote: > On Thu, Jul 9, 2020 at 4:21 PM Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: > > > > On Thursday, July 9, 2020 3:13:47 PM CEST Tomas Tomecek wrote: > > Do you expose some library which makes the conversion of various formats > > of events from various forges into uniformly looking events, like: > > > > event_type: source_change > > change: > > old_code: > > code_location: git > > clone_url: <url> > > committish: <sha> > > new_code: > > code_location: git > > clone_url: <url> > > committish: <sha> > > > > The format is to be discussed (with potential consumers, or anyone > > interested), but this is what we need on Copr side basically and I suppose > > that's something everyone else needs who wants to process the code change. > > > > I think we need a precisely defined set of events which is able to handle > > not only git locations, changes, change requests (it should be flexible > > enough to reference e.g. tarballs + patches, when we needed it in future). > > > > This is basically what we need on the "event reader" side. > > This is really interesting. So far we've been only discussing > unification of webhook or message payloads on our side. All of this is > baked directly in packit-service's codebase [1] right now. Yeah, the very same situation is on our side. > The biggest problem is that on github or gitlab, one needs to explicitly > install the app or integration so the downstream service can receive the > events. Exactly what github2fedmsg is supposed to do. Exactly :-/ what I think would be nice to have one common integration in each forge on common "Fedora level". So we don't have to have team-specific integration apps (I'm just refering to the component graph I cited in original mail). > Our team should have quarterly planning in a month. Pavel, if this is > important to you, we can bring this up on the planning session and start > with the refactor/unification so that we can at least share the code for > parsing and processing of the event payloads. Sure, I mean .. it depends on how you found this useful for Packit service itself, if you think that it makes sense to define the unified event format - and if you could consume it? > Or we can set up a call and discuss directly so we all would understand > the requirements. I'll try to ping you on irc, thanks. Pavel > [1] https://github.com/packit-service/packit-service/blob/master/packit_service/service/events.py _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
