Monitor Status of Triggered Pipeline


There are situations where you may need to kick off a pipeline in another repository, and monitor the status of that build before proceeding in your current build. Such as running tests in another service and then continuing with a deploy if that pipeline is successful.

This can be accomplished by triggering the build via a run step and then polling the status of that pipeline and proceeding accordingly.


Below are the two run steps to set this up. You will need to replace (vcs) with either github or bitbucket depending on your version control system. (org) with your Organization name and (project) with your repository name. In addition, you will need to generate a personal API token and store that is an environment variable called CIRCLE_TOKEN.

- run:
    command: |
      PIPELINE_ID=$(curl --location --request POST '' \
      --header 'Content-Type: application/json' \
      --header "Circle-Token: ${CIRCLE_TOKEN}" \
      --data-raw '{
          "parameters": {
              "node-v-1": "10.1.1"
      }' | jq -r '.id')

      echo "export PIPELINE=$PIPELINE_ID" >> $BASH_ENV
- run: |
    STATUS=$(curl "$PIPELINE/workflow?circle-token=$CIRCLE_TOKEN" | jq -r '.items[].status')

    while [ "$STATUS" == "running" ]; do
      echo still running
      sleep 10
      STATUS=$(curl -s "$PIPELINE/workflow?circle-token=$CIRCLE_TOKEN" | jq -r '.items[].status')

    echo "finally done, checking final status: $STATUS"
    if [[ "$STATUS" == "success" ]]; then
      echo "Proceeding with build, as triggered pipeline was success"
      exit 0
      echo "Stopping build, triggered pipeline was not a success"
      exit 1

The first run step kicks off the pipeline to run in the other repository, optionally you can pass in pipeline parameters if needed or remove the --data-raw section. Beyond kicking off the pipeline, it also saves the pipeline ID from the generated pipeline so we can poll the status of it in the next step.

The next run step will continually check the status of the pipeline. Once that status moves from running to something else -- we will take the appropriate actions. In this case, if success we proceed with the rest of the build. If it is anything else we fail the build with an exit 1.

You can build in a delay before the status checks occur by adding a sleep X to the top of the second run step if you know that pipeline usually takes a specific amount of time to run. 

Was this article helpful?
8 out of 16 found this helpful



Article is closed for comments.