Container Contract

Each container image used as a step in a Task must comply with a
specific contract.

Entrypoint

When containers are run in a Task, the entrypoint of the container will be
overwritten with a custom binary that ensures the containers within the Task
pod are executed in the specified order. As such, it is always recommended to
explicitly specify a command.

When command is not explicitly set, the controller will attempt to lookup the
entrypoint from the remote registry. If the image is a private registry, the
service account should include an
ImagePullSecret.
The build-pipeline controller will use the ImagePullSecret of the service
account, and if service account is empty, default is assumed. Next is falling
back to docker config added in a .docker/config.json at
$HOME/.docker/config.json. If none of these credentials are available the
controller will try to lookup the image anonymously.

For example, in the following Task with the images,
gcr.io/cloud-builders/gcloud and gcr.io/cloud-builders/docker, the
entrypoint would be resolved from the registry, resulting in the tasks running
gcloud and docker respectively.

  1. spec:
  2.   steps:
  3.     - image: gcr.io/cloud-builders/gcloud
  4.       command: [gcloud]
  5.     - image: gcr.io/cloud-builders/docker
  6.       command: [docker]

However, if the steps specified a custom command, that is what would be used.

  1. spec:
  2.   steps:
  3.     - image: gcr.io/cloud-builders/gcloud
  4.       command:
  5.         - bash
  6.         - -c
  7.         - echo "Hello!"

You can also provide args to the image’s command:

  1. steps:
  2.   - image: ubuntu
  3.     command: ["/bin/bash"]
  4.     args: ["-c", "echo hello $FOO"]
  5.     env:
  6.       - name: "FOO"
  7.         value: "world"

Except as otherwise noted, the content of this page is licensed under the
Creative Commons Attribution 4.0 License,
and code samples are licensed under the
Apache 2.0 License.