Google Cloud Build Visualizer
Tags: github, go, devops, opensource
Published: 2021-11-21 08:53:21

Google Cloud Build (GCB) is a building system provided by GCP. Considering all the competitors like GitLab CI, CircleCI and Travis CI, GCB is definitely not a common option for building CI CD pipeline.

In fact, I have tried to test GCB in my work at the early stage of adoption in GCP. The pros of GCB is definitely a full integration with GCP's resources. If you are using GCP and have no preference at the CI pipeline platform, I highly suggest you to try it out.

Circling back to the GCB's pipeline, all the configurations are written in JSON or YAML format. Here is an example for the GCB configuration.
```
steps:

  - id: 'compile web app'
    name: 'gcr.io/cloud-builders/npm'
    dir: 'web'
    args: ['install']

  - id: 'web app unit tests'
    name: 'gcr.io/cloud-builders/npm'
    dir: 'web'
    args: ['test']
    waitFor: ['compile web app']

  - id: 'build web'
    name: 'gcr.io/cloud-builders/docker'
    args: [
      'build',
      '--tag=web', # use local registry for compatibility with local builds
      '--tag=gcr.io/$PROJECT_ID/web',
      '--cache-from=gcr.io/$PROJECT_ID/web:latest',
      'web/.',
    ]
    waitFor: ['web app unit tests']

  - id: 'build db'
    name: 'gcr.io/cloud-builders/docker'
    args: [
      'build',
      '--tag=mysql', # use local registry for compatibility with local builds
      '--tag=gcr.io/$PROJECT_ID/mysql',
      '--cache-from', 'gcr.io/$PROJECT_ID/mysql:latest',
      'mysql/.',
    ]
    waitFor: ['-'] # start immediately

  - id: 'compose up'
    name: 'gcr.io/$PROJECT_ID/docker-compose:latest'
    entrypoint: '/bin/bash'
    args:
      - '-c'
      - |
        docker-compose up -d
    env:
      - 'PROJECT_ID=$PROJECT_ID'
    waitFor: ['build web','build db']

  - id: 'integration tests'
    name: 'gcr.io/$PROJECT_ID/docker-compose:latest'
    entrypoint: '/bin/bash'
    args:
      - '-c'
      - |
        ### -r = retries; -i = interval; -k = keyword to search for ###
        ./test/test-connection.sh -r 20 -i 3 -u http://web:3000
        ./test/test-content.sh -r 20 -i 3 -u http://web:3000 -k 'Chocolate Chip'
    waitFor: ['compose up']

images:
  - gcr.io/$PROJECT_ID/web
  - gcr.io/$PROJECT_ID/mysql
```

Look intuitive? Yeah! It looks intuitive. It only has the following rules in the pipeline sequence.

1. No parallel by default
2. You can specify the `waitFor` to specify the dependencies. Each dependencies will be executed in parallel.
3. You can use special character `-` to specify this step for job without dependency to run in parallel. 

So, what is the problem with GCS? The issue here is that the UI itself does not provide you with a clear view on how the steps are depended on each other. Here is an example.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8fikxpk7on5fxw1nuebj.png)
Here, you can see the steps are showed in sequential manner. You cannot observe if this build has been executed in parallel.

Therefore, I have tried to build a simple CLI to make sure we can understand how the steps are depended.
{% github ryansiu1995/gcb-visualizer %}

In this project, I built the CLI with cobra and graphviz. The logic is so simple that it will intake the JSON or YAML file. Then, it parses the configuration and turn the pipeline into a graph. Finally, the graph can be visualized by graphviz.

You can get the CLI easily with the following command.
```
go get -u github.com/ryansiu1995/gcb-visualizer
```

Go to the link and check it out if you are using GCB in your company or personal project. It definitely helps you to understand how you have configured your pipeline in GCB.

Please feel free to open an issue if you have configured out any features you want in the GCB Visualizer!