The idea is here that a workflow for docker images is composed with Jenkins responding webhooks fired from the docker hub - and integration testing/approving docker images (via some user-defined workflow) - before it pushes back changes (indicating said approval/next steps).
In this world Docker Hub is responsible for building the actual image binary from the Github source - and storing the image. Of course - in any real world workflow you need more than build and storage - and this is what Jenkins is for - Jenkins can cope with arbitrarily complex workflows - INCLUDING human approval steps, integration testing and more. Once the Jenkins-based workflow is passed - it can “push back” the image (it may start another step in the Hub, or it may simply tag the image as “production”).
So this is what the 2 arrows to/from Jenkins in the above picture - the arrow to jenkins is notification - the arrow back is confirmation.
At the time of the keynote demo, this was partly hand rolled code to make that all work. Afterwards, I spoke with Aaron and we decided this could not stand. Looking quickly at the webhook api from the docker hub Nicolas (with a tiny bit of help from me) wrote a Docker Hub plugin to automate the webhook side of things for Jenkins - so Jenkins can now respond directly to the webhook feature that is built into the Docker hub - using the /dockerhub-webhook/ URL that the plugin adds to your Jenkins instance (needs to be public facing for the Docker Hub webhook call to reach it of course).
The separation of concerns is clear: Docker Hub for building a binary image, and storing, Jenkins for workflow, unit testing, integration testing etc. The “docker build” step was not designed to encompass unit or integration testing steps - it is about producing a portable binary image in the form of file system layers in a reproducible way.