Cl/CD for Gitlab repositories with Cloud Build repositories Gen2

The trailhead for any path to production starts at source control. The integration of Cloud Build, as the automation tool, with the source repository is therefore crucial to increasing the delivery speed and ultimately becoming a high-performing organization.

In this article we look at two exciting new capabilities of the recently launched second generation of Cloud Build repositories. First, Cloud Build can now connect to source code repositories in Gitlab and Gitlab Enterprise. And second, repository connections can now be managed declaratively in Terraform. We will now dive into a simple end-to-end demonstration to experience both of these features.

Preparing the Gitlab Environment

For our demo we use a private repository that is hosted on Gitlab.com. If you already have a Gitlab repository with a Cloud Build configuration, you can set the GITLAB_REPO_URI variable to the HTTPS URI of your repository and continue with the next section.

To create a minimal Gitlab repository to experiment with Cloud Build you can perform the following steps:

1. Create a private repo in Gitlab.com. I am using cloud-build-demo as the name here.

2. Store the repo URI as the variable GITLAB_REPO_URI in my case this is: GITLAB_REPO_URI='https://gitlab.com/<USER>/cloud-build-demo.git' (you can use ssh for the local clone to the workstation but we'll use HTTPS for the Cloud Build Repository below

3. In a terminal (e.g. cloud shell or locally) initialize the repository with a cloudbuild.yaml config as follows:

You should now see your repository content (in our case just the cloudbuild.yaml file) in the Gitlab web UI.

Preparations in Google Cloud

To get started we need to ensure that our Google Cloud project has the necessary APIs for Cloud Build and Secret Manager enabled on the project. Our example requires us to add the two services to a Terraform configuration or to run the following commands in a terminal:

Cloud Build repositories are authenticated at the level of a so-called host connection. The authentication process of a host connection is specific to the source code repository and differs slightly between Gitlab and Github. For host connection to access repositories in Gitlab you need to issue personal access tokens for both the api and read-api scope as described in the document Connect to a GitLab host.

Once you have issued the tokens you can store them as environment variables GITLAB_API_TOKEN and GITLAB_READ_API_TOKEN and run the command below to create secrets in Secret Manager. If you look closely you’ll find that we will also create the required secret for Gitlab webhooks but we won’t use them for this demo. In a last step we also authorize the Cloud Build Service Agent to use the secrets that we just created such that it can establish the host connection.

Note: You could create these secrets in Terraform as well but the plain text values will be visible in your tf state.

Configuring the Cloud Build Repository and triggers with Terraform

With the authentication credentials configured in Secret Manager we can move on to the Terraform configuration. For simplicity we put everything in a single main.tf file that looks as follows:

We provide variables for the Google Cloud project ID, references to the externally created secrets in Secret Manager, and an optional location override for the Cloud Build resources.

The Cloud Build specific Terraform resources are:

• google_cloudbuildv2_connection to specify the host connection with a name, region and the credentials. Host connections can be used by multiple repositories so the credentials can be managed centrally.

• google_cloudbuildv2_repository to specify the Gitlab repo we want to use and associate it with a host connection. This requires that the host connections’ credentials have access to the repository specified as remote_uri.

• google_cloudbuild_trigger to run the Cloud Build pipeline on push events on any branch in the Gitlab repository.

To apply the Terraform configuration we execute the following two commands from within the folder that contains our main.tf file:

Once the resources are created, we can see them in the Google Cloud Console under Cloud Build > Repositories:

To test our simple pipeline and the repo trigger we can push an empty commit to our sample repo:

In the Cloud Build dashboard in the Google Cloud Console you can see the build that was kicked off.

The same result is visible in the Gitlab UI under Builds > Pipelines.

Next steps

You can find more information about Cloud Build repositories and a side by side comparison of the features of the Gen 1 and Gen 2 repositories in the official Cloud Build repositories documentation. If you are planning to use Cloud Build with a Git repository hosted on GitHub, you should follow these instructions for your Terraform configuration.