Open call for new gateways

[krancour]

⚠️ Important: Our community is always welcome to propose, develop, or even donate new gateways. We do, however, suggest discussing ideas with project maintainers first since we will sometimes have knowledge of efforts that are underway outside our own organization. A quick discussion right here in this thread or on the Brigade channel of the Kubernetes Slack may go a long way toward preventing duplication of efforts.

⚠️ In addition to the above, anyone wishing to develop a new gateway as part of Google Summer of Code should propose the specific integration they wish to develop in their GSoC'22 application and should hold off on performing that work until formally paired with our project.

This issue is an open invitation to our community to create (and possibly donate) new Brigade v2-compatible event gateways (or other event sources). A brief overview follows:

Brigade is an event-driven scripting platform built on top of Kubernetes. Brigade projects subscribe to different types of events from different sources and define, through script, how to handle those events. This could be used for anything event-driven, really. Implementing CI/CD workflows that are triggered by various events (webhooks) originating from GitHub is, for instance, a popular use for Brigade, but the only limitation is your imagination.

Brigade itself is not pre-integrated with any event sources. Event gateways are peripheral components that are installed alongside Brigade to receive events from external systems, transform those events into Brigade events, and use the Brigade API to enqueue those events on Brigade's internal event bus.

This diagram summarizes succinctly:

Most gateways are small, simple programs. On the more sophisticated end of the spectrum, however, gateways could go so far as to utilize the Brigade API to monitor the status of events they have created and report those statuses "upstream" to the original source of the event.

Contributions of "other event sources" are also welcome. This is our catch-all term for software that, unlike a gateway, emits original events into Brigade that did not originate from some external/upstream system. Good examples of these would be our cron event source or the noisy neighbor.

Gateways and other event sources that already exist (at various stages of maturity):

• GitHub
• Bitbucket
• Docker
• Azure Container Registry (Likely to be archived before GA because the CloudEvents Gateway can also work with ACR)
• Slack
• Noisy Neighbor
• Cron

@jorgearteiro and some of his colleagues might have already begun work on Teams and Discord gateways.

Further reading:

• https://docs.brigade.sh/topics/design/
• https://docs.brigade.sh/topics/project-developers/events/
• https://docs.brigade.sh/topics/operators/gateways/

⚠️ Anyone wishing to develop a gateway or other event source as part of GSoC'22, please read on!

A modest degree of Brigade foreknowledge would be an asset to a successful candidate, although intimate familiarity with its codebase is not required since you would be engaging in green field development of a component with a relatively narrow scope. Strong Go, TypeScript or JavaScript skills are a must since those are the languages for which the Brigade SDK (API language bindings) are readily available. Go is preferred. Prior experience with Kubernetes and experience developing Helm charts would also be strongly preferred, as there is an expectation that gateways are hosted on Kubernetes and are installed via Helm. Strong written communication skills will also be essential, as your new gateway will require thorough documentation and is incomplete without it.

The expected outcome of your GSoC project would be the GA release of a new gateway that you will donate to the Brigade project.

Green field development of an average gateway is a medium difficulty project that a qualified candidate can complete with roughly 175 hours of effort.

[AnuragThePathak]

Hello, I was thinking of working on this issue for GSOC 2022. I have gone through the gateway page of docs.
To learn more about developing gateways will I need to directly checkout codebase of any of the existing gateways or there are other resources available?

[krancour]

@AnuragThePathak I've been told that this is the official place for discussing this.... I'll copy your question over to there and answer there also.

[AnuragThePathak]

@AnuragThePathak I've been told that this is the official place for discussing this.... I'll copy your question over to there and answer there also.

Oh sorry I can ask there again if you want.

[nate-double-u]

@AnuragThePathak I've been told that this is the official place for discussing this.... I'll copy your question over to there and answer there also.

I'm sorry, I didn't mean to imply that the discussions boards are the official, or only, place to discuss the projects or ask questions. I'm very happy for questions to be asked and answered on these upstream issues as well!

I opened the discussion boards as another avenue, perhaps more central, but no more official. I thought a central spot may help with common questions, or to help folks find similar projects.

[krancour]

Ah. Thanks for the clarification @nate-double-u. If it's all the same, I'm going to keep directing people there regardless because it's easier for me to keep the discussions consolidated instead of fragmented.