Writing a Build Configuration
The CI/CD pipeline featured here works pretty simply. GCP listens for changes in your source control, either new commits on a specific branch, or new pull requests. Then, it sends the source to Cloud Build, which runs a set of commands to test and build the application, and sends the output build artifacts over to App Engine, GKE, Cloud Functions, or a Cloud Storage bucket.
Most of the configuration for Cloud Build actually happens outside of Cloud Build, in a YAML file called cloudbuild.yaml. This defines the build steps, options, and output settings. The schema looks something like this:
You won’t need all of these options though. A simple configuration like the following will build an NPM application and deploy it to a Cloud Storage bucket:
The first key, “Steps,” runs npm install to get dependencies in order, then npm test to run any tests you have set up, then npm run build to start the build process. After that completes, output artifacts in the build folder are sent to gs://mybucket/. You don’t have to deploy to an output bucket though; Cloud Build supports deployments to GKE, Cloud Functions and Cloud Run, and App Engine.
Ultimately though, this step will highly depend on what kind of application you’re building, so we can’t write a step-by-step guide for everyone. We recommend reading Google’s configuration overview to learn more.
Setting Up Cloud Source & Cloud Build
Once you have a build configuration, you can set up Cloud Build to handle the actual builds. Cloud Build gets its source from Cloud Source, Google’s own hosted Git solution. If you want to use your own git though, you can link an external account, or just set up Cloud Source as a secondary release remote.
Head over to Cloud Source and create a new repository. You can sign in with Github or Bitbucket to link an external account and select a repository, or just create a new one and add it as a secondary remote.
Head over to Cloud Build, and click “Set Up Build Trigger” from the dashboard.
Give it a name, select the source repository, and choose when you want this trigger to run. You can trigger based on commits to a certain branch, new tags, or pull requests. You can also use regex to match the branch names.
You’ll want to keep the default here for the Cloud Build configuration file, but if you gave it a different name or placed it under a different path, you can select that here. You also have the option of setting custom variables, which will let you re-use configuration with multiple triggers on different branches.
Click create, and the trigger will appear in the dashboard. You can manually run the trigger here to test your settings.
Once it’s set up though, it will run automatically on every push to the branch, or pull request, depending on what you configured.
