Publish images via pulse rather than dockerhub.

[tomprince]

This is a prototype of using pulse to publish docker images to cloudops.

It uses a task with a route
cloudops.deploy.v1.<project>.<environment>
and an extra of

cloudops-deploy:
    image-task-id: <image-task-id>
    variant: <variant>

The idea is that mozilla-services/cloudops-deployment-proxy#18 will listen to these messages, and trigger the corresponding jenkins job. The jenkins jobs would then check chain-of-trust of the provided image task-id, and load the docker image included there.

The idea of including project/environment in the route, and the variant (here admin or public; in scriptworker-scripts it would be the script), is that the former should be protected by scopes, and I'm inclined to say that the the variant does not need to be so protected.

I'm mostly interested in feedback on the API at this point, rather than any of the implementation details.

[rail]

It looks straight forward. I assume that we will add per project scopes, to prevent cross project pushes.

[tomprince]

Yeah, routes are controlled by scopes, so we will only grant the appropriate branches the scopes to publish on the given routes (so dev and production branches can't publish to each others routes).

[escapewindow]

We might be able to parameterize this in the k8s-image task, and use single_dep to create a push-image task per k8s-image task. I don't think that's a massive win with 2 k8s-image tasks, so I think this is a perfectly fine implementation.

[tomprince]

Yeah, I was definitely thinking more about the shape of the resulting tasks, than taskgraph details. Your idea of encoding it in the build task makes sense. If we do that, we could also use that as a check in cloudops-infra-deploylib, that the image was intended to be used for where the hook is telling it to use it. I suspect that would make secops happy; I know that when @ajvb was reviewing the hg stuff for ci-admin, having checks for the info received via pulse was desirable.