Is it possible to force a rebuild of an upstream pipeline from the downstream receiver?

Follow

Comments

3 comments

  • Avatar
    Shilpa Goley

    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?  

  • Avatar
    Ian Bridson

    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 failing


    I'd love to know what you would use this for!

  • Avatar
    LeeBenhart

    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

Please sign in to leave a comment.