The future for webhook-to-fedora-messaging

Project Discussion
1

Hey folks!

Last summer we have added an application to replace github2fedmsg, because it was running on RHEL7 and was the last blocking bit to move to RHEL8 and drop fedmsg. Since RHEL7 was already EOL, we were a bit in a rush and stopped at the minimal viable product for webhook-to-fedora-messaging (called W2FM from now on).
It’s now running in production and most repos that had registered with github2fedmsg have been migrated.
However, there are still some parts that are missing:

  1. a UI to add new services
  2. support for other types of webhooks

That’s two projects that I’d like to propose to the community. The latter is easier so let’s start with it. We currently have a discourse2fedmsg app that we could migrate into W2FM. We could also start supporting Gitlab and Forgejo webhooks.

The UI project is a little more complex. The application is written in Python with the FastAPI framework. So it’s not very well suited to outputting HTML. It is however well suited for Javascript UIs, just as we did in FMN.
A UI would need to use OIDC login, which is possible with statically-generated HTML or with Javascript UIs (again, as in FMN).
Ideally, as a stretch goal, the UI would let users login to external services as well (like Github), offer possible repos to register, and set their webhooks directly. The old github2fedmsg was capable of that, it was very nice.
Between static HTML and a Javascript UI, I would personnaly prefer a Vite-based, JS UI, as in FMN.

I would be happy to mentor people from the community who would be intersted in those two projects. Please reach out if this sounds interesting and fun to you!

1 Like
2

I think these are great!

I hope there’s some interest out there to work on them…

3
  1. a UI to add new services

+1

It is only when I came back to the codebase for implementing the Forgejo support that I realized how much of a pain it is to add services.

  1. support for other types of webhooks

I think that this should be on a need-to-achieve basis because it is only then that we would have maintainers for the platform support.

For someone who needs GitLab webhooks support, I think they would be more inclined to ensure that things stay running for that platform.

The UI project is a little more complex. The application is written in Python with the FastAPI framework. So it’s not very well suited to outputting HTML. It is however well suited for Javascript UIs, just as we did in FMN.
A UI would need to use OIDC login, which is possible with statically-generated HTML or with Javascript UIs (again, as in FMN).
Ideally, as a stretch goal, the UI would let users login to external services as well (like Github), offer possible repos to register, and set their webhooks directly. The old github2fedmsg was capable of that, it was very nice.
Between static HTML and a Javascript UI, I would personnaly prefer a Vite-based, JS UI, as in FMN.

Vite is a development toolchain - I think you meant Vue (because FMN uses Vue).

Likewise, for the mentorship side of things, once I clear things off my backlog - I would be interested to mentor folks (or heck, pair-program).

4

Correct!