What does "gcloud builds submit ... " do? - google-cloud-platform

Question

I would like to know what gcloud builds submit does. In my case I am running the GCloud run tutorial.
The official documentation states that it submits a build. This is not a particularly helpful piece of information.
Can someone provide some more context to this?
What is a build? An Image? A jar file? Where is this 'build' being submitted to?
What does 'submitting' mean? Does this 'submit' process push my 'build' over the network.
When I run gcloud builds submit it also seems to be creating a docker image. So this is also creating the build, and then it is submitting it ?!!??

Answer 1

There are several steps that's happening when you run the gcloud builds submit command:
Compresses your application code, Dockerfile, and any other assets in the current directory as indicated by .;
Uploads the files to a Cloud Storage bucket (there's a default bucket but you're free to specify a bucket on your build config);
Initiates a build using the uploaded files as input;
Tags the image using the provided name; and
Pushes the built image to Container Registry.
On your case, a build is a docker container that is pushed/submitted into the Container Registry. Once it's submitted, you'll be able deploy that container on Cloud Run just as specified on the docs you've provided.

Answer 2

Cloud Build is a service that applies one or more container images in series to some initial set of input files and often generating some artifacts, often (not always) another container image, often some source code that was initially submitted that the service builds into a container image.
Cloud Build is somewhat analogous to e.g. Linux pipelines where some input is transformed by piping data through a series of commands: f | g | h | .... Alternatively you may think of it as composited functions: h(g(f(x))).
Cloud Build is described (and named) as a service to build (code into containers) but, as you know, actually the steps may be any container image and often these have side-effects such as deploying container images to other services e.g. Cloud Run.
Cloud Build is much more general-purpose than Google advertises it. Google limits its scope in its documentation to a cloud-based service to build software.
When you run gcloud builds submit... you provide some source code and either a Dockerfile or a configuration file. The former is a simple case of the second, a configuration file containing a single step that runs docker build....
Configuration files (YAML) list a series of container images with parameters that are run in series. Initially Cloud Build copies a designated source (can be the current directory) to a Compute Engine VM (created by the service) as a directory (that's automatically mounted into each container) as /workspace.
Containers (defined as steps in the configuration file) may operate on this file system (e.g. compline code, validate files, anything that you can do in a container). Often, in conclusion, config files store containers that have been created in e.g. Container Registry.
Solving Quadratic equations with Cloud Build
Cloud Build can be confusing to newcomers. In a spirit of fun and as a way to show that Cloud Build is quite general-purpose, here's a Rube Goldberg machine written in Cloud Build that solves quadratic equations:
For the following cloudbuild.yaml:
steps:
- name: busybox
args:
- ash
- -c
- 'echo "Quadratic: $(cat a)x²+$(cat b)x+$(cat c)s=0"'
- name: busybox
args:
- ash
- -c
- 'echo "$(cat b) * $(cat b)" | bc -l > b2'
- name: busybox
args:
- ash
- -c
- 'echo "4 * $(cat a) * $(cat c)" | bc -l > 4ac'
- name: busybox
args:
- ash
- -c
- 'echo "$(cat b2) - $(cat 4ac)" | bc -l > b2-4ac'
- name: busybox
args:
- ash
- -c
- 'echo "sqrt($(cat b2-4ac))" | bc -l > sqrt'
- name: busybox
args:
- ash
- -c
- 'echo "-($(cat b)) + $(cat sqrt)" | bc -l > add'
- name: busybox
args:
- ash
- -c
- 'echo "-($(cat b)) - $(cat sqrt)" | bc -l > sub'
- name: busybox
args:
- ash
- -c
- 'echo "2 * $(cat a)" | bc -l > 2a'
- name: busybox
args:
- ash
- -c
- 'echo "$(cat add)/$(cat 2a)" | bc -l > root1'
- name: busybox
args:
- ash
- -c
- 'echo "$(cat sub)/$(cat 2a)" | bc -l > root2'
- name: busybox
args:
- ash
- -c
- 'echo "Roots are: $(cat root1); $(cat root2)"'
It expects 3 files (a, b, c) in ${PWD} containing the values of ax²+bx+c=0. So, for 8x²-10x+3:
echo "8" > a
echo "-10" > b
echo "3" > c
You can run it with:
gcloud builds submit ${PWD} \
--config=./cloudbuild.yaml \
--project=${PROJECT}
Explanation Rube Goldberg Cloud Build machine for solving Quadratic equations

Answer 3

A build is the process of creating artifacts from a source, and optionally modifying the state of any system you have access to.
An artifact can be a text file, a Docker container image or a Java archive.
To submit a build is to send your build resources (source files) to Cloud Storage, on the one hand. On the other hand, it is also to create a worker, which is a Google-managed GCE instance in a pool of instances dedicated to builds, instances that scale horizontally on demand and are destroyed when their assigned build is finished.
The worker reads the source files from Cloud Storage, and executes each build step in the configuration file, creating a Docker container for each step.
Each container executes the script in each respective step.
The concatenaton of container script executions is the build, properly speaking, and it produces artifacts.
There is always at least one artifact, a text file with the build log, which is pushed to Cloud Storage, and there can be container images or Java archives also produced as artifacts, which are pushed to the Container Registry.
I wouldn't say there is a difference between "create" and "submit" a build, but, if there is, it might be that "creating" a build is all the build from preparation to end, or preparing the source files, having the environment ready (project, permissions, quota, etc.), and "submitting" it would be just issuing the command submit or having a trigger submit it for you.