Support for Webhook

[tduchateau]

Hi,

It would be awesome to have the support for Webhook as in the official hub in the registry API! What do you think?

[dmp42]

There is an extension mechanism in v1: https://github.com/docker/docker-registry/tree/master/docker_registry/extensions on top of which I think it's fairly easy to implement webhooks.

There is also a notification mechanism inside the v2 registry: https://github.com/docker/distribution/tree/master/notifications

Thought admittedly the documentation is pretty sparse right now :)

[michaelneale]

@dmp42 the public docker hub STILL uses the old non notifications format, so for people that want to support both it and private registries you get a very different and clumsy experience (config for private registry is via yml, not via setting a per repo webhook, which is another weirdness).

Do I have this right? I can't reconcile the inconsistency.

[dmp42]

@michaelneale yeah, the Hub and privately operated registries are really two different beasts, with widely different targets and use cases. The Hub is really meant as a zero maintenance, pure SAAS system, while operating a private registry gives you both more control, and more "responsibility" in implementing your own pipeline.

Whether the APIs should be unified or not is open for debate, but if you ask me, the kind flexibility you find in registry:2 (https://github.com/docker/distribution) can simply not make its way into the hub, if only for security reasons.

Hope that helps.

[michaelneale]

Thanks yes I could see that. The events Api is a superset so tools will need to expect either blob of json, which isn't too much of an issue, just a bit surprising. On Wed, 26 Aug 2015 at 5:55 pm Olivier Gambier notifications@github.com wrote:

@michaelneale https://github.com/michaelneale yeah, the Hub and privately operated registries are really two different beasts, with widely different targets and use cases. The Hub is really meant as a zero maintenance, pure SAAS system, while operating a private registry gives you both more control, and more "responsibility" in implementing your own pipeline.

Whether the APIs should be unified or not is open for debate, but if you ask me, the kind flexibility you find in registry:2 ( https://github.com/docker/distribution) can simply not make its way into the hub, if only for security reasons.

Hope that helps.

— Reply to this email directly or view it on GitHub https://github.com/docker/docker-registry/issues/982#issuecomment-134888245 .

[michaelneale]

@dmp42 makes sense. Do you think the private registry will layer on a hub like "simple" webhook or will the generic events api/json be the one true way? (I understand those events aren't appropriate for the saas hub).

[dmp42]

@michaelneale I believe the open-source registry is meant to provide lower-level "primitives", powerful base "bricks" that advanced users can leverage by integrating with other micro-services that in turn deliver higher-level functionalities.

For example, the registry should be just CRUD, and the notification API kept as-is (generic json events) - then developers can come up with a standalone notification-endpoint that receive these, and transform/spit them back into either a queue (celeri, rabbit, whatever) or as "simple" webhooks.

Put otherwise: the registry is meant to be extended and built upon.

If you are looking for a universal hub&registry compatible pipeline into your "app", then you should add such an intermediate notification endpoint micro service between your registry and your app that will turn registry notifications into simple webhook similar to hub.

In the hope that helps.

[kmadel]

Will the Docker backed 'Trusted Registry' support either setting endpoints for registry notificaitons and/or webhooks similar to what is available on Docker Hub?

[dmp42]

@kmadel DTR supports whatever we ship with the open-source registry. Appart from them, if you want a specific feature in it, you should ask for it on the support.