Ability to supply custom webhook for post-upload etc.

[jdolitsky]

cc @verchol @itaysk @olegs-codefresh

[olegsu]

@jdolitsky Thank for bringing it. To start with, here are some references that I found useful:

• https://webhooks.pbworks.com/w/page/13385124/FrontPage
• https://developer.github.com/webhooks/
• http://progrium.com/blog/2007/05/03/web-hooks-to-revolutionize-the-web/
• http://timothyfitz.com/2009/02/09/what-webhooks-are-and-why-you-should-care/

"Webhooks provide a way for notifications to be delivered via Http request to an external web server whenever certain actions occur" - Github

Suggestion

This is a proposal for a webhook implementation. It includes some basic overview on a webhook (information and requirements) and more specific details about how Chartmuseum should implement it (which API expose and how to register)

General

• Must be well defined and versioned
• Must always send Http POST request
• Must keep the given URL (including the query params)
• Can be configured to send secret in the header. Securing Github webhooks
• The Http response must have 2XX status code ( retry policy should be discussed)
• Https validation (optional validation of secure connection to the server)

Chartmuseum

• Webhooks are opt-in via flag
• Testing hooks
• Save the history of the sent webhooks alongside with the received status and resend option

Security

https://support.elastic.io/support/solutions/articles/14000044772-securing-your-webhooks

Implementation

Chartmuseum should define 3 entities

• Integration - Created by the user and defines which event should be the trigger to send the webhook for which resources (chart atm)
• Event - created by the system, has a name and additional data about the state.
• Webhook - an entity that created for event & trigger pair and be sent to the server

Spec

The spec that I'd like to propose will be very similar to Kubernetes resources so new users can adapt it easily.

• Integration
  • Version: v1
  • Kind: integration
  • Metadata:
    • Name
    • ID
    • Labels
  • Spec:
    • Triggers: [string]
    • URL
    • Resources:
      • Chart
      • Repo
    • Secret
• Webhook:
  • Version: v1
  • Kind: webhook
  • Metadata:
    • Action
    • Timestamp
    • Integration:
      • Id
      • Name
  • Spec:
    • Chart
    • Resource:
      • Type
      • Name

Storage

Chartmuseum should be able to be executed as a standalone application, from this statement we must support storage in 2 ways:

1. In memory
2. Any other db, sql, redis ...

[k]

Looks like this could get some inspiration from: https://docs.docker.com/registry/notifications/

[guoweikuang]

I think this feature is especially useful. I want to ask what is the current situation.

[soloradish]

Hi, Is there any update on this topic? I really want to use this feature to streaming events into our notification pipe line.

[marshall-orevillestudios]

Oh man I wish this was already a feature!