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/appBasefor your application and all services have a FROM
foo/appBase:latestin their Dockerfiles. With this new feature, you can easily trigger builds for all your services if the base image
- 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 -
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.
resources: - name: payload_params type: params version: 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 job. We 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 shippable.jobs.yml file and commit the file.
jobs: - name: u14nod_runCI type: runCI steps: - OUT: payload_params - name: sample_nodejs_runCI type: runCI steps: - 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 python: - 2.7 build: pre_ci: #build docker image - docker build --rm -t manishas/u14nod:tip . pre_ci_boot: image_name: drydock/u14nod image_tag: tip pull: false ci: # We can add sanity checks to ensure the image was built successfully here - . ~/.nvm/nvm.sh - nvm ls on_success: - if [ "$IS_PULL_REQUEST" != true ]; then docker push manishas/u14nod:tip; fi - shipctl post_resource_state "payload_params" "versionName" "$BRANCH.$BUILD_NUMBER" integrations: hub: - 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!