Building repositories from GitHub Enterprise

Stay organized with collections Save and categorize content based on your preferences.

Cloud Build enables you to create triggers on a GitHub Enterprise instance. This page explains how you can use GitHub Enterprise triggers to invoke builds in response to commits or pull requests from a GitHub Enterprise instance.

Before you begin

  • Enable the Cloud Build and Secret Manager APIs.

    Enable the APIs

Creating a GitHub Enterprise trigger

This section explains how you can create a trigger and link it your GitHub Enterprise installation. If you want to use GitHub Enterprise triggers in a private network, see Building repositories from GitHub Enterprise in a private network for further instructions.

Console

To create GitHub Enterprise triggers using the Google Cloud console:

  1. Open the Triggers page in the Google Cloud console.

    Open the Triggers page

  2. Select your project from the project selector drop-down menu at the top of the page.

  3. Click Open.

  4. Click Create trigger.

  5. Enter the following trigger settings:

    • Name: Enter a name for your trigger.

    • Region: Select the region for your trigger.

      You must select a non-global region for your trigger.

      If the build config file associated with your trigger specifies a private pool, Cloud Build uses the private pool to run your build. The region you specify in your trigger must match the region where you created your private pool.

      If the build the build config file associated with your trigger does not specify a private pool, Cloud Build uses the default pool to run your build in the same region as your trigger.

    • Description (optional): Enter a description for your trigger.

    • Event: Select the repository event to invoke your trigger.

      • Push to a branch: Set your trigger to start a build on commits to a particular branch.

      • Push new tag: Set your trigger to start a build on commits that contain a particular tag.

      • Pull request (Cloud Source Repositories not supported): Set your trigger to start a build on commits to a pull request.

    • Source: Select 2nd generation as your source.

      • Repository: From the list of available repositories, select the desired repository. To connect a new repository, see Connect to a GitHub Enterprise repository.

      • Branch or Tag: Specify a regular expression with the branch or tag value to match. For information on acceptable regular expression syntax, see RE2 syntax.

      • Comment control: If you selected Pull request (GitHub App only) as your Event, choose one of the following options to control whether a build will automatically be executed by the trigger:

        • Required except for owners and collaborators: When a pull request is created or updated by a repository owner or collaborator, builds will automatically be executed by the trigger. If an external contributor initiates the action, builds will only be executed after an owner or collaborator comments /gcbrun on the pull request.

        • Required: When a pull request is created or updated by any contributor, builds will only be executed after an owner or collaborator comments /gcbrun on the pull request. Builds are executed each time a change to a pull request is made.

        • Not required: When a pull request is created or updated by any contributor, builds will automatically be executed by triggers.

    • Included files (optional): Changes affecting at least one of these files will invoke a build.

    • Ignored files (optional): Changes only affecting ignored files will not invoke a build.

    • Configuration: Select the build config file located in your remote repository or create an inline build config file to use for your build.

      • Type: Select the type of configuration to use for your build.
        • Autodetected: Cloud Build autodetects your configuration type if you have a cloudbuild.yaml or Dockerfile in your repository.
        • Cloud Build configuration file (yaml or json): Use a build config file for your configuration.
        • Dockerfile: Use a Dockerfile for your configuration.
        • Buildpacks: Use buildpacks for your configuration.
      • Location: Specify the location for your configuration.

        • Repository: If your config file is located in your remote repository, provide the location of your build config file or the Dockerfile directory and a name for the resulting image. If your configuration is a Dockerfile, you can optionally provide a timeout for your build. When you've provided the Dockerfile and image name, you'll see a preview of the docker build command that your build will execute.
        • Inline: If you selected Cloud Build configuration file (yaml or json) as your configuration option, you can specify your build config inline. Click Open Editor to write your build config file in the Google Cloud console using YAML or JSON syntax. Click Done to save your build config.
    • Substitution variables (optional): If you selected the Cloud Build config file as your build config option, you can choose to define trigger-specific substitution variables using this field. For example, say you're creating multiple triggers where each trigger deploys your app to a specific environment. You can specify that your app is deployed to an environment in your build config file and then use this field to define substitution variables specifying which environment this trigger should deploy to. For information on specifying substitution values in build config files, see Substituting variable values.

    • Build logs (optional): Check the box to send build logs to GitHub. To learn how to view build logs, see Viewing build logs.

    • Service account: Select the service account to use when invoking your trigger. If you do not select a service account, the default Cloud Build service account is used.

  6. Click Create to save your build trigger.

To create GitHub triggers using gcloud commands, see the gcloud commands for Creating a build trigger.

gcloud

To create GitHub Enterprise triggers using gcloud commands, run the following command:

gcloud alpha builds triggers create github \
  --name=TRIGGER_NAME \
  --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
  --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
  --build-config=BUILD_CONFIG_FILE \
  --region=REGION

Where:

  • TRIGGER_NAME is the name of your trigger.
  • PROJECT_ID is your Google Cloud project ID.
  • REGION is the region for of your trigger.
  • CONNECTION_NAME is the name of your GitHub Enterprise connection.
  • REPO_NAME is the name of your repository
  • BRANCH_PATTERN is the branch name in your repository to invoke the build on.
  • TAG_PATTERN is the tag name in your repository to invoke the build on.
  • BUILD_CONFIG_FILE is the path to your build configuration file.

Data sharing

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

The following data is currently shared between Cloud Build and GitHub Enterprise:

  • Cloud project ID
  • Trigger name
  • Build logs

If you created triggers prior to August 2020, data sharing may not be enabled for your project. You can enable data sharing for all GitHub Enterprise triggers in your project by clicking Enable on the Cloud Build Data sharing tab.

If you have required status checks enabled for a GitHub Enterprise repository, enabling data sharing may temporarily break status checks. You can adjust status check configurations to look for your trigger name by:

  • Disabling any Cloud Build-specific required checks on the GitHub Enterprise repository
  • Ensuring that data sharing is enabled in Cloud Build
  • Executing a new build in Cloud Build that posts statuses to your repository
  • Re-enabling required status checks, selecting trigger name

Next steps