Email bridge for GitLab

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Konstantin, Daniel,

Thanks for the feedback on my GitLab talk yesterday.  Sorry I missed
the post talk discussion.

I know that creating a usable but distributed collaboration forum with
a forge (preferably email) is a challenging problem.

The problem presented:
How to collaborate across different forge based workflows or email
based workflows?
How to keep the entry bar low for contributors?
How to handle situations where the forge is down for a few hours, can
work still get done?

Most of the above problems indicate 'email' is the common method for
handling them.



I wanted to throw out the email bridge the Red Hat kernel developed
using Patchwork v2, celery and an http server as the core piece plus
added scripts glued together.  Considering kernel.org has a lot of
those pieces there, it might not be a stretch to implement this.

Anyway, throwing this out as a conversation starting solution:
patchlab (https://github.com/jeremycline/patchlab).  Thanks to Jeremy
Cline for thinking and implementing this!

How does it work?
(assuming a running instance of Patchwork and an http server)

Email -> GitLab
 * email sent to list and shows up on Patchwork as designed
 * Patchwork uses hook to call separate django DB table that maps PW
PatchID to GitLab MR
   * If not found, adds entry
   * kick off celery job
     * Comments use GitLab token to add comment to MR
     * New patches are applied locally in new branch and git push'd as new MR
     * Failed to apply patches are dropped
     * Updated patch updates MR

GitLab -> Email
  * GItLab updates will send webhooks to http server with Patchwork
    * comments convert GitLab MR to PW PatchID
      * use msgid and cc fields to send email reply
     * new MRs are cloned locally
       * git format-patch ; git-send-email
       * Add email header to avoid loop
       * Sent email circles around to populate Patchwork DB
         * extra email header will block further processing in above celery job

We have been running this publicly for almost a year now.
Email list : https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx/
GitLab project: https://gitlab.com/cki-project/kernel-ark/-/merge_requests

I know this isn't the most simple or elegant solution, but it solved
our needs for now.  Happy to entertain better ideas or thoughts!

Thoughts?

Cheers,
Don




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux