[DO NOT MERGE] Build lifecycle hooks #3674
Conversation
|
@rhcarvalho I don't agree with not supporting this for custom builds. i'm not sure why DCs don't support it, but i don't see a compelling reason for us not doing it...i agree it's not strictly necessary since the builder image could do it, but if you're moving logic between build strategies it'd be nice to keep something as a hook. |
|
@rhcarvalho also should make it clear the hook will only run if the build succeeds, at least right now. |
|
@bparees, I've updated the type definitions to include the Post hook on CustomBuildStrategy too. |
|
@bparees as you suggested in IRC, added a field to allow one to specify the Docker image used to run the hook's container. |
|
What's the card for this? |
|
Want to see the use cases this is intended to solve - builds and deployments are very different in their effects (deployment is external, build is internal). How do I easily notify a third party web hook when my build completes? I have to create an image and customize a pod template? |
|
@smarterclayton card is here: https://trello.com/c/Sk3aSNxG/516-13-build-lifecycle-hooks-build the reason we evolved away from a straight up webhook (while recognizing a significant loss in convenience) is the challenge in doing a webhook generically. it's one thing to say "we're going to call the endpoint of your choice with a payload of our definition" but it's another to say "we'll call the endpoint of your choice with the payload your endpoint demands" which is what you really need to do things like trigger a jenkins build downstream. and then you add in complications like ssl certs, secrets/passwords/etc and it quickly spiraled. So rather than try to solve all those things and come away with something that only worked for webhooks, we decided for now to just implement a fully generic solution which can be used to solve the webhook problem and anything else you want to do (eg send an email, run tests, whatever). the implementation will require you provide a shell script to invoke. That could be in the builder image, or in your application repo (so it gets installed as part of the build). Or it can be a separate image of your choice, but the lowest impact option is one of the first two. you do not have to customize a pod template, you would customize the buildconfig to define the post-build-hook, the things you'd specify would be the image in which to run the hook (possibly defaulting to the output image of the buildconfig) and the path to the script to run. |
|
I should note we have followup cards to revisit specific scenarios like "after my build foo runs, trigger build bar" or "when a build completes for foo, trigger my build bar" which we plan to implement to provide a way to do those things w/o implementing a shell script, but we figured ultimately we need both the quick/easy/limited solution and the generic one, so let's do the generic one and get our bases covered, then come back and make specific use cases simpler. |
|
So what sorts of use cases would we have for the generic hook? What On Jul 13, 2015, at 11:02 PM, Ben Parees notifications@github.com wrote: I should note we have followup cards to revisit specific scenarios like — |
|
The deployment books had very concrete use cases that justified their implementation. These hooks need to have likewise - something has to prove their value. |
|
The use cases for this hook are:
|
|
Origin Action Required: Pull request cannot be automatically merged, please rebase your branch from latest HEAD and push again |
|
A further wrinkle - if the hook can't run on the exact image that was built, we can't really offer that option to users ("latest" isn't good enough). |
|
How is the information about the build going to be passed into the hook pod? |
probably the same way we pass it into the build itself... env variable on the pod containing the json serialization of the build object. as for running the hook on the exact image the build produced, yeah that's a challenge certainly since we don't currently record the imageid a build produced anywhere. |
|
Back to the white board, started with a proposal identifying use cases for build hooks, and how each solution relates to them #3736 |
|
On Jul 14, 2015, at 11:11 PM, Ben Parees notifications@github.com wrote: How is the information about the build going to be passed into the hook pod? probably the same way we pass it into the build itself... env variable on as for running the hook on the exact image the build produced, yeah that's We probably want to record the name, namespace, and uid of the build that — |
I've inspected two images, one built with Source strategy and one with Docker strategy, and found that both have there build name, namespace and source (repo URL) as ENVs, and no build information as labels. Also noted that although we have the "source", we don't have the "contextDir". Should I open a new issue to track that? I think those changes can be addressed parallel to build hooks, and can be useful even without hooks... |
|
@mfojtik was adding at least some of that information in s2i builds I thought. |
|
Closing this as we decided not to implement build hooks now. |
Add lifecycle hooks to builds, similar to existing Deployment lifecycle hooks.
Pre: not supported because there is no Docker image to run the hook before a successful buildAbort: not supported because cannot abort a build that has been completed