A lot of the features of Cloud Build rely on connection with git workflows.
RepoSource() could be a mirror of your GitHub or other git provider. If you are using a Build Trigger (next section) then the source is automatically configured to be your trigger source.
Once your repo is mirrored it gives you a Cloud Repository name which is of the form
github_username_repo - this you can add to a
Cloud Build triggers let you automate builds based on git pushes or pull requests via
cr_buildtrigger_repo(type="github") lets you link to push and pull events on GitHub repositories you have given permission for GCP to access via the GitHub Cloud Build app -
cr_buildtrigger_repo(type="cloud_source") lets you link to push events to Google Cloud Source Repostitories - this can include a mirror of GitHub or other git providers such as BitBucket
An example setting up
cr_buildtrigger_repo() with GitHub is shown below - this will trigger builds when you push to the master branch:
cloudbuild <- system.file("cloudbuild/cloudbuild.yaml", package = "googleCloudRunner") bb <- cr_build_make(cloudbuild, projectId = "test-project") # setting up the trigger event github <- cr_buildtrigger_repo("MarkEdmondson1234/googleCloudRunner", branch = "master") cr_buildtrigger(bb, name = "trig1", trigger = github)
By default the above will act via cloning your repo at the start of any build. You may want to use git further within your cloud build steps, such as commiting the results of your build back to the repository.
This can be done within your build by using
cr_buildstep_git(). If you are doing non-public operations (such as committing and pushing) then you will need to set up GitHub authorization for the build to do so - the easiest method is to use Google Secret Manager to save a ssh key for your git securely, and then accessible via
cr_buildstep_secret(). This can be set up once and then used for any future builds you create.
Cloud Build needs permission to commit to git, so the first step is to create an ssh key secret that it will use to work on your behalf.
The guide is for GitHub, adapt it if you use another git provider:
.pub) to GitHub’s SSH keys
.pub) to Google Secret Manager -
https://console.cloud.google.com/security/secret-managerand call it a name such as
Secret Manager Secret AccessorIAM role assigned to the cloudbuild service email (
In general the secret can be downloaded via
cr_buildstep_secret() which takes two arguments - the name of the secret and the location of where the decrypted file should be within your workspace.
A rundown on some common workflows and connections are detailed here.
A common use case is creating a pkgdown website of your package. This involves building the website upon each git commit, creating the new pkgdown HTML then committing that back to the GitHub repo so it can display the page using GitHub page hosting.
cr_deploy_pkgdown("MarkEdmondson1234/googleCloudRunner", secret = "my_git_secret")
By default this will create a cloudbuild-pkgdown.yml file in your repo that holds the buildsteps to build and commit your website, and create the buildtrigger that will run this build upon each commit to the master branch.
If you want the Docker image to rebuild each git commit, then you also need a build trigger. This can be enabled using
cr_deploy_docker_trigger()and point it at your Dockerfile folder
cr_deploy_docker_trigger() will create a buildtrigger that will build the Dockerfile upon each commit.
The below example builds this package’s GitHub repo and its Dockerfile upon each commit, for a Dockerfile located in the