Triggering a sequential, parameterized build after continuous integration

- By Manisha Sahasrabudhe on May 24, 2016

We are happy to announce the addition of sequential parameterized builds to our feature list. Using this feature, you can trigger a sequence of CI workflows for your projects and even pass parameters from one build to another!

You will want to do this in 2 situations:

  • You have build dependencies, and if one codebase changes, you want to trigger builds for all dependent codebases. A great example of this is that you have a base Docker image foo/appBase for your application and all services have a FROM foo/appBase:latest in their Dockerfiles. With this new feature, you can easily trigger builds for all your services if the base image appBase changes.
  • You have codebases that need to be triggered sequentially since each build produces parameters required by the next build in the sequence.

Let's look at a more detailed example of how this will work in practice.


For this example, I have 2 GitHub repositories - devopsrecipes/u14nod which has the Dockerfilefor base nodejs image that i use for my application, which is at devopsrecipes/sample_nodejs. I want to set up my CI workflow for the base image so that every time it changes, it also triggers CI for the application and also passes a parameter.

Both projects are enabled on Shippable.



They are two configuration files that are needed to achieve this usecase -

  • Resources  are defined in your shippable.resources.yml file, that should be created at the root of your repository. Please find an overview of resources here.

  • Jobs  are defined in your file, that should be created at the root of your repository. Please find an overview of jobs here.

These files should be committed to your source control and can exist in a separate repository or any one of the respositories used in this sample. In our example, we have created them in the devopsrecipes/u14nod respository. Step 4 of the workflow below will describe how to add the config to Shippable.



 1. Define the paramater to pass to sample_nodejs.

payload_params is a params resource used to specify key-value pairs. We define a single key-value pair that represents the parameter to pass for CI.

Add the following yml block to your shippable.resources.yml file and commit the file.

  - name: payload_params
    type: params
        TRIGGER_REASON: "BaseImgChanged"


2. Specify payload_params as input to the CI for sample_nodejs.

Every repository enabled in Shippable for CI is represented by a runCI jobWe specify payload_params as an input to the CI for sample_nodejs and output from the CI from u14nod using the runCI job for both these repositories.

Add the following yml block to your file and commit the file.

  - name: u14nod_runCI
    type: runCI
      - OUT: payload_params
  - name: sample_nodejs_runCI
    type: runCI
      - IN: payload_params


3. Trigger payload_params from devopsrecipes/u14nod.

Here is the shippable.yml file for u14nod, which builds and pushes the docker image to Docker hub.

language: python

  - 2.7

    #build docker image 
    - docker build --rm -t manishas/u14nod:tip .

    image_name: drydock/u14nod
    image_tag: tip
    pull: false

    # We can add sanity checks to ensure the image was built successfully here
    - . ~/.nvm/
    - nvm ls

    - if [ "$IS_PULL_REQUEST" != true ]; then docker push manishas/u14nod:tip; fi
    - shipctl post_resource_state "payload_params" "versionName" "$BRANCH.$BUILD_NUMBER"

    - integrationName: "docker hub integration"
      type: "docker"

The shipctl post_resource_state command creates a new version of the payload_params resource. This triggers the sample_nodejs_runCI job since this resource is an input to the job. Refer shipctl reference docs for more information.


4. Add config to Shippable

Once you have these jobs and resources yml files as described above, commit them to your repository. This repository is called a Sync repository.

Follow these instructions to import your configuration files into your Shippable account.


And that's it! Triggering a build for the base image will now trigger CI for the application if CI for the base image passes. You have successfully set up sequential, parameterized builds.

Let us know if you have any questions or want to share your feedback! Happy Shipping!

Try Shippable

Topics: Shippable updates