webhook2fedmsg

Purpose

This investigation’s goal is to explore a possible new application that will convert webhooks from different services to Fedora messaging messages.

Resources

Requirements

  • User can log in using FAS account

  • User can link different webhook services to FAS account

  • Application will listen for the webhook POST requests

  • Application will provide endpoint for each service

  • POST request will be validated against the known tokens for the service

  • Support for GitHub

  • Support for Discourse

  • CI - Recommending Zuul CI or Github Actions

  • Documentation - Documentation could be hosted on readthedocs.org

  • OpenShift deployment

  • Unit tests - Recommending tox

  • Fedora messaging schema

  • Easy to use dev env - Recommending either vagrant or containerized environment

Nice to have

List of features that would be nice to have.

  • Document how to create webhooks on every service

  • Document how to generate token on every service

  • Support for GitLab

  • Support for MediaWiki

  • Automatic dependency management - Recommending renovate

  • API for managing tokens

  • Automatic deployment in OpenShift

Investigation

Following it the design document for webhook2fedmsg.

The Good Points

  1. Supports multiple webhook services

  2. Easier to maintain - less codebases

  3. Easier to add new webhook service in future

  4. Users can manage tokens by themselves

  5. With this solution we don’t need to rewrite github2fedmsg - one less initiative

The Bad points

  1. Initial work - completely new app

  2. Another application to maintain - However this will allow us to get rid of few others

  3. Manual work with tokens and webhooks on webhook service side for users

Conclusions

This application will help us to lower our codebase. We wouldn’t need to maintain multiple applications service2fedmsg anymore, but everything that provides webhook could be managed by this application. It is definitely something we have knowledge and skills to do.

Proposed Roadmap

  • Step 1 - Write new app with tests and documentation

  • Step 2 - Create separate repository with message schemas

  • Step 3 - Deploy in staging

  • Step 4 - Inform community this service is available for testing

  • Step 5 - Deploy in production

  • Step 6 - Community blog announcing this new service

Estimate of work

This work will need at least 2 developers, one with web frontend skill set. The estimation for this project is 12 weeks.