Each container image that executes a
Step in a
comply with the container contract described in this document.
Task instantiates and runs containers that execute the
Steps in the
entrypoint is overwritten with a custom binary that ensures the
containers within the
Task's Pod are executed in the order specified in the
definition. Because of this, we highly recommend that you always specify a
However, if you’re using the
script field to
embed a script within a
Step, do not specify a
command value. For example:
- name: setup-comment image: python:3-alpine script: | #!/usr/bin/env python import json (...)
If you do not specify a
command value, the Pipelines controller performs a lookup for
entrypoint value in the associated remote container registry. If the image is in
a private registry, you must include an
value in the the service account definition used by the
The Pipelines controller uses this value unless the service account is not
defined, at which point it assumes the value of
The final fallback occurs to the Docker config specified in the
If no credentials are specified in any of the locations described above, the Pipelines
controller performs an anonymous lookup of the image.
For example, consider the following
Task, which uses two images named
gcr.io/cloud-builders/docker. In this example, the
Pipelines controller retrieves the
entrypoint value from the registry, which allows
Task to execute the
docker commands, respectively.
spec: steps: - image: gcr.io/cloud-builders/gcloud command: [gcloud] - image: gcr.io/cloud-builders/docker command: [docker]
However, if you specify a custom
command value, the controller uses that value instead:
spec: steps: - image: gcr.io/cloud-builders/gcloud command: - bash - -c - echo "Hello!"
You also have the option to specify
args to go with your
steps: - image: ubuntu command: ["/bin/bash"] args: ["-c", "echo hello $FOO"] env: - name: "FOO" value: "world"
Was this page helpful?
Thanks! Tell us how we can further improve.
Sorry about that. Tell us how we can further improve.