On Thursday, July 9, 2020 3:13:47 PM CEST Tomas Tomecek wrote:
Pavel, thanks for bringing this up!
Funny thing is that you just described a lot of functionality of packit as a
Yes, I believe. Same as the github2fedmsg, which is somewhat close as
well, I even mentioned you in the original email ;)
getting events from multiple sources (fedora-messaging, CentOS'
mqtt, GitHub webhooks, GitLab webhooks, prod/stg) and then have a mechanism to
process those and provide updates. Big heads-up to everyone - it took us year+
to get such functionality, polish it, make it secure, scalable, auditable,
maintainable. It's a ton of work.
If there is anything we can do to help, please let us know.
Do you expose some library which makes the conversion of various formats
of events from various forges into uniformly looking events, like:
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.
(one of the core components of packit's architecture is our
, which serves as an abstraction layer on top of gitforge APIs -
pagure, github, gitlab)
I've seen that one... That sounds like library for actively communicating
over APIs with forges. That's surely one part needed for sending back the
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines