Trigger downstream builds

Issue #13232 open
Jens Gram
created an issue

I'm currently surveying Pipelines in order to see if our current Jenkins-based setup can be ported. It seems promising but I've searched for one key feature with no luck:

My setup is as follows: a "core" package is built from branch develop on changes. Build includes testing + deploy to Artifactory. Furthermore, I have a bunch of components (submodules.) These too are continuously built from branches develop. Both "core" and components belong to the same team.

What I'm looking for is some way to manually trigger a Pipelines build for branches develop on all components when develop on "core" is successfully built and deployed. A workaround would be to push a change to a dummy file on each component but that seems a bit of a hack to me.

Is there anything I have missed in the documentation? What I would like is something like the following in "core":

pipelines: 
  branches: 
    develop: 
      - step: 
          script: 
            - ant -f build.xml my_ant_target_to_build_and_deploy
          downstream:
            - component1:develop
            - component2:develop
            - 

Official response

  • Matt Ryall staff

    Thanks for the suggestion. While we don't have direct support for this yet in Pipelines, you can use a workaround of setting up a custom pipeline on your dependencies, and using our REST API to trigger them when your main pipeline completes.

    Describing all the steps is a bit complex for this comment, but the nuts and bolts are in our documentation here:

Comments (32)

  1. Mads K

    It would be cool if it was generic, and not just sub-modules! I need that feature too, and it would be a show-stopper without the ability to trigger other builds!

  2. Matt Ryall staff

    Thanks for the suggestion. While we don't have direct support for this yet in Pipelines, you can use a workaround of setting up a custom pipeline on your dependencies, and using our REST API to trigger them when your main pipeline completes.

    Describing all the steps is a bit complex for this comment, but the nuts and bolts are in our documentation here:

  3. Jens Bannmann

    For reference, here is my use case from Issue #13661:

    Java Maven builds: when we land a new pull request in our framework's current SNAPSHOT version (develop branch), the current commit of the dependent product (on its develop branch) needs to be rebuilt. For release builds (commits on master), this is not necessary as those have fixed versions, not SNAPSHOT versions.

  4. Cory Robinson

    +1 Almost every project I work on has this dependency and we're having a hell of a time porting our projects to Pipelines from Circle CI because of this shortcoming :-(

  5. Caleb Cushing

    I like this idea, but I would like it inverted. Dockerhub has a feature where you can rebuild your images when an upstream image is re-released. So with my example yaml this would run anytime a new v tag was pushed, and the upstream tag pipeline that matches v* passed. In this way anyone who wanted to do a trigger on a release of an open source BB project could.

    pipelines:
      upstream:
        - xenoterracide/entity-api:tags/v*
            exec: default
    
  6. Xinchao Zhang

    Agree that it would be smarter to specify upstream repositories rather than downstream repositories. A core repo should have zero idea that who will be depending on it.

  7. Log in to comment