Build repositories from GitLab Enterprise Edition in a private network

Cloud Build enables you to create triggers to build from repositories hosted on GitLab Enterprise Edition, allowing you to execute builds in response to events such as commit pushes or merge requests associated with your GitLab Enterprise Edition repository.

This page explains how you can enable trigger functionality on a GitLab Enterprise Edition instance if your instance is hosted in a private network.

Before you begin

  • Enable the Cloud Build, Secret Manager, Compute Engine, and Service Networking APIs.

    Enable the APIs

Build repositories from GitLab Enterprise Edition in a private network

If your GitLab Enterprise Edition instance is only accessible within a VPC network, you need to set up a Service Directory service and build using private pools. The project containing your VPC network can exist in a different project than the one containing your Service Directory service. Use the following instructions to ensure your instance is reachable prior to creating triggers:

  1. Enable the Service Directory API.

  2. Ensure you have the Project IAM Admin role granted to the Google Cloud project you intend to create your Service Directory service in. To learn how to grant IAM roles, see Configuring access to Cloud Build resources.

  3. Set up a Service Directory service by completing the following steps:

    1. Configure a namespace for your Google Cloud project.

      The region you specify in your namespace must match the region you specify in your Cloud Build host connection.

    2. Configure a service in your namespace.

    3. Configure an endpoint for your registered service.

      When configuring an endpoint, you must use an internal IP address and specify an HTTPS port number in order for Cloud Build to reach your service.

    To learn more about private network access configuration, see Configure private network access. Service Directory also provides integration with services such as load balancers and Google Kubernetes Engine (GKE). To learn more, see Service Directory and load balancing overview or Service Directory for GKE overview.

  4. Grant Service Directory access to the Cloud Build Service Agent:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
    gcloud projects add-iam-policy-binding PROJECT_ID_CONTAINING_SERVICE_DIRECTORY_RESOURCE \
       --member="serviceAccount:${CLOUD_BUILD_SERVICE_AGENT}" \


    • PROJECT_ID is your Google Cloud project ID.
    • PROJECT_ID_CONTAINING_SERVICE_DIRECTORY_RESOURCE is the project ID containing your Service Directory resource.
  5. Grant the Service Directory Viewer role to your Cloud Build service account, service-${PROJECT_NUMBER}

  6. Grant the Private Service Connect Authorized Service role to your Cloud Build service account to allow access to your VPC network resource, service-${PROJECT_NUMBER} You must grant the role in the project that contains your VPC network.

  7. Use private pools to run your builds. If you have not created a private pool, see create a new private pool.

  8. Follow the instructions to create a GitLab Enterprise Edition trigger to build repositories hosted on a GitLab Enterprise Edition instance.

    If you include a self-signed or private certificate when connecting your GitLab Enterprise Edition host to Cloud Build, you must set the host URI as the Subject Alternative Name (SAN) of your certificate.

Your GitLab Enterprise Edition trigger will now automatically invoke builds on your GitLab Enterprise Edition instance based on your configuration.

Data sharing

The data sent to GitLab Enterprise Edition from Cloud Build helps you identify triggers by name and see build results on your GitLab Enterprise Edition repositories.

The following data is shared between Cloud Build and GitLab Enterprise Edition:

  • Google Cloud project ID
  • Trigger name

What's next