When you deploy your function's source code to Cloud Functions, that source is stored in a Cloud Storage bucket. Cloud Build then automatically builds your code into a container image and pushes that image to Container Registry. Cloud Functions accesses this image when it needs to run the container to execute your function.
The process of building the image is entirely automatic and requires no direct input from you. There is, however, a slight difference between the process for the older Node.js 8 and Go 1.11 runtimes and the current process for all other runtimes: Java 11, Python 3.7, Python 3.8, Node.js 10 and Go 1.13.
Node.js 8 and Go 1.11 runtimes
For older runtimes, the build process takes place not in your user project, but in a related project, called the tenant project. Running the build in a tenant project solved some issues associated with those runtimes, but also created some new issues:
Because the build does not occur in your project, you do not have access to the build logs to sort through any build issues you might run into.
This process requires an internal daily build-time quota, which, under certain fairly common circumstances, can be exhausted. This can limit your ability to deploy any new source code until the quota is replenished.
You do not have any access to the Container Registry where your function's container image is stored, so you have no way to view your available images.
For newer runtimes not mentioned above such as Java 11+, Python 3.7+, Node.js 10+, and Go 1.13+, all the resources used in the build process now execute in your own user project, not the tenant project. This is now the default process.
Executing the build process within your project means that:
You have direct access to all build logs.
There is no preset build-time quota, although Cloud Build does have its own default concurrency quota.
You can view the current container image and the previously deployed container image, both of which are stored in Container Registry.
Because Cloud Storage is used directly in your project, the source code directory for your functions is visible, in a bucket named
Characteristics of the default process
As a result of this change, all runtimes using the default process have the following characteristics:
The Cloud Build API must be enabled for your project.
To enable the API manually click the above link, select your project from the dropdown menu, and click Continue.
Because the entire build process takes place within the context of your project, the project is subject to the pricing of the included resources:
For Cloud Build pricing, see the Pricing page. This process uses the default instance size of Cloud Build, as these instances are pre-warmed and are available more quickly. Cloud Build does provide a free tier: please review the pricing document for further details.
For Cloud Storage pricing, see the Pricing page. Cloud Storage does provide a free tier: please review the pricing document for further details.
For Container Registry pricing, see the Pricing page.
Because the build process is subject to billing, your project must have a Cloud Billing Account attached to it.
Accessing your build image logs
A key benefit of having the build image process in your user project is access
to build logs. You can use either the
gcloud CLI or the Cloud Console
to reach the logs, which are available through Cloud Logging.
Deploy your function using the
gcloud functions deploycommand.
The URL of the logs is shown as part of the response in your terminal window. For example:
Deploying function (may take a while - up to 2 minutes)...⠹ **For Cloud Build Stackdriver Logs**, visit: https://console.cloud.google.com/logs/viewer?project=
&advancedFilter=resource.type% 3Dbuild%0Aresource.labels.build_id%3D38d5b662-2315-45dd-8aa2- 380d50d4f5e8%0AlogName%3Dprojects%2F % 2Flogs%2Fcloudbuild Deploying function (may take a while - up to 2 minutes)...done.
From the Functions screen, click the Name of the function in which you are interested. The Function Details page opens.
Scroll down until you see the Container build section. If your build had no errors, you see a link you can follow to display the Build log. If your build had errors, as you see below, the Container build section shows them inline; click Learn more to display the Build log directly.
The Log viewer screen opens. Click the entry in which you are interested.
The complete build log entry opens, showing the file affected, a description of the error - in this case a missing bracket in the
pom.xml, and the line and column of the error.