{"action":"created","issue":{"url":"https://api.github.com/repos/openshift/origin/issues/1228","repository_url":"https://api.github.com/repos/openshift/origin","labels_url":"https://api.github.com/repos/openshift/origin/issues/1228/labels{/name}","comments_url":"https://api.github.com/repos/openshift/origin/issues/1228/comments","events_url":"https://api.github.com/repos/openshift/origin/issues/1228/events","html_url":"https://github.com/openshift/origin/issues/1228","id":59933179,"number":1228,"title":"add a build completed notification so that we can chain builds together to make a Deployment Pipline","user":{"login":"jstrachan","id":30140,"avatar_url":"https://avatars.githubusercontent.com/u/30140?v=3","gravatar_id":"","url":"https://api.github.com/users/jstrachan","html_url":"https://github.com/jstrachan","followers_url":"https://api.github.com/users/jstrachan/followers","following_url":"https://api.github.com/users/jstrachan/following{/other_user}","gists_url":"https://api.github.com/users/jstrachan/gists{/gist_id}","starred_url":"https://api.github.com/users/jstrachan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jstrachan/subscriptions","organizations_url":"https://api.github.com/users/jstrachan/orgs","repos_url":"https://api.github.com/users/jstrachan/repos","events_url":"https://api.github.com/users/jstrachan/events{/privacy}","received_events_url":"https://api.github.com/users/jstrachan/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/openshift/origin/labels/component/build","name":"component/build","color":"0052cc"},{"url":"https://api.github.com/repos/openshift/origin/labels/kind/enhancement","name":"kind/enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/openshift/origin/labels/priority/P3","name":"priority/P3","color":"fad8c7"}],"state":"open","locked":false,"assignee":{"login":"bparees","id":4974046,"avatar_url":"https://avatars.githubusercontent.com/u/4974046?v=3","gravatar_id":"","url":"https://api.github.com/users/bparees","html_url":"https://github.com/bparees","followers_url":"https://api.github.com/users/bparees/followers","following_url":"https://api.github.com/users/bparees/following{/other_user}","gists_url":"https://api.github.com/users/bparees/gists{/gist_id}","starred_url":"https://api.github.com/users/bparees/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bparees/subscriptions","organizations_url":"https://api.github.com/users/bparees/orgs","repos_url":"https://api.github.com/users/bparees/repos","events_url":"https://api.github.com/users/bparees/events{/privacy}","received_events_url":"https://api.github.com/users/bparees/received_events","type":"User","site_admin":false},"milestone":null,"comments":31,"created_at":"2015-03-05T10:31:49Z","updated_at":"2016-04-08T17:35:07Z","closed_at":null,"body":"TL;DR; add a new build trigger kind to BuildConfig, so a build B can be triggered if build A completes succesfully. i.e. OpenShift would automatically fire the web hooks for build B if build A completes without having to hard code the web hook of B into the build docker container of A.\r\n\r\n\r\nNow the background...\r\n\r\nTo implement [Continuous Delivery](http://en.wikipedia.org/wiki/Continuous_delivery) we need to setup a [Deployment Pipeline](http://martinfowler.com/bliki/DeploymentPipeline.html) between environments which includes integration/soak/UAT tests, manual approval steps and so forth.\r\n\r\nOpenShift already has almost everything required for this right now (e.g. a namespace can be used for each environment, there's web hooks for triggering builds & deployments and builds can be fairly flexible things running docker containers).\r\n\r\nThe missing thing - from what I can see - is we can't chain arbitrary builds together. i.e. I want to trigger build B if build A completes successfully. There doesn't seem to be a way to notify with a web hook that a build completed successfully.\r\n\r\ne.g. lets imagine a relatively simple sequential deployment pipeline such as this using 2 namespaces and a manual approval to production:\r\n\r\n1. git push hook \r\n2. STI image build updates\r\n3. deploy new image on staging namespace\r\n4. kick off a soak test and if that passed...\r\n5. fire an approval process (e.g. a PR on a git repo using gerrit or raising an issue or something)\r\n6. when approved this build is triggered to move the production tag on the image\r\n7. when the product tag is changed on an image deploy it into the production namespace\r\n\r\nSo right now 1-3 can be done already with git push hooks & deploymentConfig triggered by image change. 4 can be done (I think) by triggering a soak test build via image change.\r\n\r\nThe approval build (5) there's no way to fire that if (4) succeeds; without hard coding the build 4 to know to fire a web hook on build  5 inside the build itself.\r\n\r\nTo implement 5->6 we could use a PR which maybe does the docker tag as part of a build or something; or just a build which is fired by a web hook in the approval process or something.\r\n\r\n\r\nOften these CD pipelines can get complex; they often involve fork/join builds; where when an image changes you may wish to kick off parallel builds (e.g. a soak test, load test and UAT test in different environments/namespaces). So it'd be nice to be able to join things together so that when all those things succeed, then the next build step is kicked off. \r\n\r\nWhat would be cooler is if we could leave builds, triggers and deployments as loosely coupled, plug and play things and just compose them together to make pipelines (so that each build isn't hard coded to know what the next build step is - so builds can be reusable). It feels the docker-ish thing to do; to make builds do one thing well; then compose them together. A build docker container (STI or otherwise as builds may not generate new docker images they may just test/approve/update tags/perform PRs) should not know or care about whats next in the pipeline.\r\n\r\nSo it'd be nice if a BuildConfig could specify as a trigger the other build (or even builds) which it depends on. e.g. we could configure BuildConfig for B to have a trigger when BuildConfig A completes succesfully. Then we could configure Build C to have a trigger on build B. When whenever build A completes, OpenShift would look for all the other BuildConfigs which have a \"build complete trigger\" for A - which would result in B being triggered. If/when build B completes then build C would be triggered.\r\n\r\nSince a BuildConfig can have many triggers a build E could be triggered by C and D. If we need a join step in a pipeline (only do something if C and D are built successfully) then that could be a separate stateful build to figure out when its complete (and so fire the next step). e.g. we could use something like Gerrit +1 voting for now as an implementation detail - but this would be something internal to the build docker image to figure out. Another approach would be a stateful docker container which keeps track of which builds have been completed for a given version/image so that it fails the build until all the required things are done.\r\n\r\nIn many ways though the joining part is an implementation detail inside a build docker image. All OpenShift would need to do would be fire builds which have the 'build completed trigger' when other builds complete successfully (to avoid having to hard code firing of web hooks inside the build docker images).\r\n\r\nThoughts?\r\n\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/openshift/origin/issues/comments/207529804","html_url":"https://github.com/openshift/origin/issues/1228#issuecomment-207529804","issue_url":"https://api.github.com/repos/openshift/origin/issues/1228","id":207529804,"user":{"login":"bparees","id":4974046,"avatar_url":"https://avatars.githubusercontent.com/u/4974046?v=3","gravatar_id":"","url":"https://api.github.com/users/bparees","html_url":"https://github.com/bparees","followers_url":"https://api.github.com/users/bparees/followers","following_url":"https://api.github.com/users/bparees/following{/other_user}","gists_url":"https://api.github.com/users/bparees/gists{/gist_id}","starred_url":"https://api.github.com/users/bparees/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bparees/subscriptions","organizations_url":"https://api.github.com/users/bparees/orgs","repos_url":"https://api.github.com/users/bparees/repos","events_url":"https://api.github.com/users/bparees/events{/privacy}","received_events_url":"https://api.github.com/users/bparees/received_events","type":"User","site_admin":false},"created_at":"2016-04-08T17:35:07Z","updated_at":"2016-04-08T17:35:07Z","body":"was just coming in here to make the same comment @jstrachan made 8 months ago, i think this should be closed in deference to the jenkins pipeline work we're doing.  We already tried to implement this feature once (trigger builds when a build completes) and ended up deciding against it.\r\n\r\n@smarterclayton @jstrachan any objection to closing this?\r\n"}}