Is it possible to force a rebuild of an upstream pipeline from the downstream receiver? LeeBenhart Updated September 27, 2016 18:27 Follow Assuming two pipelines, upstream1 and downstream1 is it possible to FORCE upstream1 to rebuild from downstream1? Related articles Go's Dependency Management Different Types of Triggers for a Pipeline Comments 3 comments Sort by Date Votes Shilpa Goley September 22, 2011 06:49 In general, a pipeline can be manually triggered via UI or by using a Go Api (which can be used from within a script)Could you explain your scenario in little more detail, though? 0 Permalink Ian Bridson September 22, 2011 08:39 Taking this literally i don't think it would work, as upstream1 would not have the material from downstream1 in the first place to trigger in order to create downstream1 output.If the question is more about how to trigger upstream1 from downstream1, then without material from downstream1 I am not sure that there is any influence that downstream1 can have on upstream1. Under what conditions would you want downstream1 to force the build?If it was because downstream1 failed a test say, then you could create an artifact only when the test failed, and feed that back into the first stage of upstream1, once you have run this manually at least once to get the artifacts in the first place. Then make the stage approval automatic and I think you would get a trigger of upstream1 every time a new artifact was created, with the first stage of upstream1 doing nothing but triggering stage 2 (which fetches code and does the build etc so that check-ins don't trigger the upstream1 build). This would give you a rebuild of upstream1 when downstream1 failed. you would then need some kind of retry limit to avoid looping if the downstream1 kept failingI'd love to know what you would use this for! 0 Permalink LeeBenhart September 22, 2011 21:05 This came up in discussion in my shop as there is not desire to set the pipelines to autoUpdate and autoStart on checkin. However, we also do not want to have to remember all the upstream dependencies (if any) to make sure everything is built with the latest source changes. What is prefered is to setup our product pipeline, have it trigger all of the dependent pipelines and wait until those are completed, prior to commencing with the rest of the build. So what I see in setting something like this up would be to have the primary pipeline identifiy dependencies in the materials, the first stage would be to start all the dependent builds, the next stage would then fetch the artifacts from those dependent builds and then execute from there.The concern is not getting the latest changes when a product build is started, especially since there may be multiple pipeline dependencies and there is no way to tell GO to not start if more than one of its dependencies is currently building.Thanks for the ideas, it is something I will keep in mind moving foward. Lee 0 Permalink Please sign in to leave a comment.