Esta página se ha traducido con Cloud Translation API.

Esquema del archivo de configuración de compilación

Un archivo de configuración de compilación contiene instrucciones para que Cloud Build realice tareas según tus especificaciones. Por ejemplo, el archivo de configuración de compilación puede contener instrucciones para compilar, empaquetar y enviar imágenes Docker.

En esta página se explica el esquema del archivo de configuración de Cloud Build. Para obtener instrucciones sobre cómo crear y usar un archivo de configuración de compilación, consulta Crear un archivo básico de configuración de compilación.

Estructura de un archivo de configuración de compilación

Los archivos de configuración de compilación se modelan mediante el recurso Build de la API de Cloud Build.

Puedes escribir el archivo de configuración de la compilación con la sintaxis YAML o JSON. Si envías solicitudes de compilación con herramientas HTTP de terceros como curl, utiliza la sintaxis JSON.

Un archivo de configuración de compilación tiene la siguiente estructura:

YAML

steps:
- name: string
  args: [string, string, ...]
  env: [string, string, ...]
  allowFailure: boolean
  allowExitCodes: [string (int64 format), string (int64 format), ...]
  dir: string
  id: string
  waitFor: [string, string, ...]
  entrypoint: string
  secretEnv: string
  volumes: object(Volume)
  timeout: string (Duration format)
  script: string
  automapSubstitutions: boolean
- name: string
  ...
- name: string
  ...
timeout: string (Duration format)
queueTtl: string (Duration format)
logsBucket: string
options:
 env: [string, string, ...]
 secretEnv: string
 volumes: object(Volume)
 sourceProvenanceHash: enum(HashType)
 machineType: enum(MachineType)
 diskSizeGb: string (int64 format)
 substitutionOption: enum(SubstitutionOption)
 dynamicSubstitutions: boolean
 automapSubstitutions: boolean
 logStreamingOption: enum(LogStreamingOption)
 logging: enum(LoggingMode)
 defaultLogsBucketBehavior: enum(DefaultLogsBucketBehavior)
 pool: object(PoolOption)
 pubsubTopic: string
 requestedVerifyOption: enum(RequestedVerifyOption)
substitutions: map (key: string, value: string)
tags: [string, string, ...]
serviceAccount: string
secrets: object(Secret)
availableSecrets: object(Secrets)
artifacts: object(Artifacts)
  goModules: [object(GoModules), ...]
  mavenArtifacts: [object(MavenArtifact), ...]
  pythonPackages: [object(PythonPackage), ...]
  npmPackages: [object(npmPackage), ...]
images:
- [string, string, ...]

JSON

{
    "steps": [
    {
        "name": "string",
        "args": [
            "string",
            "string",
            "..."
        ],
        "env": [
            "string",
            "string",
            "..."
        ],
        "allowFailure": "boolean",
        "allowExitCodes: [
            "string (int64 format)",
            "string (int64 format)",
            "..."
        ],
        "dir": "string",
        "id": "string",
        "waitFor": [
            "string",
            "string",
            "..."
        ],
        "entrypoint": "string",
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "timeout": "string (Duration format)",
        "script" : "string",
        "automapSubstitutions" : "boolean"
    },
    {
        "name": "string"
        ...
    },
    {
        "name": "string"
        ...
    }
    ],
    "timeout": "string (Duration format)",
    "queueTtl": "string (Duration format)",
    "logsBucket": "string",
    "options": {
        "sourceProvenanceHash": "enum(HashType)",
        "machineType": "enum(MachineType)",
        "diskSizeGb": "string (int64 format)",
        "substitutionOption": "enum(SubstitutionOption)",
        "dynamicSubstitutions": "boolean",
        "automapSubstitutions": "boolean",
        "logStreamingOption": "enum(LogStreamingOption)",
        "logging": "enum(LoggingMode)"
        "defaultLogsBucketBehavior": "enum(DefaultLogsBucketBehavior)"
        "env": [
            "string",
            "string",
            "..."
        ],
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "pool": "object(PoolOption)"
        "requestedVerifyOption": "enum(RequestedVerifyOption)"
    },
    "substitutions": "map (key: string, value: string)",
    "tags": [
        "string",
        "string",
        "..."
    ],
    "serviceAccount": "string",
    "secrets": "object(Secret)",
    "availableSecrets": "object(Secrets)",
    "artifacts": "object(Artifacts)",
      "goModules": [object(GoModules), ...],
      "mavenArtifacts": ["object(MavenArtifact)", ...],
      "pythonPackages": ["object(PythonPackage)", ...],
      "npmPackages": ["object(npmPackage)", ...],
    "images": [
        "string",
        "string",
        "..."
    ]
}

Cada una de las secciones del archivo de configuración de compilación define una parte de la tarea que quieres que ejecute Cloud Build:

Fases de compilación

Una fase de compilación especifica una acción que quieres que realice Cloud Build. En cada paso de compilación, Cloud Build ejecuta un contenedor Docker como instancia de docker run. Los pasos de compilación son análogos a los comandos de una secuencia de comandos y te ofrecen la flexibilidad de ejecutar instrucciones arbitrarias en tu compilación. Si puedes empaquetar una herramienta de compilación en un contenedor, Cloud Build puede ejecutarla como parte de tu compilación. De forma predeterminada, Cloud Build ejecuta todos los pasos de una compilación de forma secuencial en la misma máquina. Si tienes pasos que se pueden ejecutar simultáneamente, usa la opción waitFor.

Puedes incluir hasta 300 pasos de compilación en tu archivo de configuración.

Usa el campo steps del archivo de configuración de compilación para especificar un paso de compilación. Aquí tienes un fragmento del tipo de configuración que puedes definir en el campo steps:

YAML

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/mydepl', 'my-image=gcr.io/my-project/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image"
            "deployment/mydepl"
            "my-image=gcr.io/my-project/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
            "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`name`

Usa el campo name de un paso de compilación para especificar un cloud builder, que es una imagen de contenedor que ejecuta herramientas comunes. En un paso de compilación, se usa un compilador para ejecutar las tareas.

En el siguiente fragmento se muestran los pasos de compilación que llaman a los compiladores bazel, gcloud y docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/bazel'
...

- name: 'gcr.io/cloud-builders/gcloud'
...

- name: 'gcr.io/cloud-builders/docker'
...

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/bazel"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/gcloud"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/docker"
        ...
    }
    ]
}

`args`

El campo args de un paso de compilación toma una lista de argumentos y los transfiere al compilador al que hace referencia el campo name. Los argumentos que se transfieren al compilador se transfieren a la herramienta que se está ejecutando en el compilador, lo que te permite invocar cualquier comando admitido por la herramienta. Si el compilador usado en el paso de compilación tiene un punto de entrada, los argumentos se usarán como argumentos de ese punto de entrada. Si el compilador no define un punto de entrada, se usará el primer elemento de args como punto de entrada y el resto se usará como argumentos.

Puedes crear hasta 100 argumentos por paso. La longitud máxima de los argumentos es de 10.000 caracteres.

El siguiente fragmento invoca el comando docker build e instala las dependencias de Maven:

YAML

steps:
- name: 'gcr.io/cloud-builders/mvn'
  args: ['install']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/mvn",
        "args": [
            "install"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`env`

El campo env de un paso de compilación toma una lista de variables de entorno que se usarán al ejecutar el paso. Las variables tienen el formato KEY=VALUE.

En la siguiente configuración de compilación, el campo env del paso de compilación define la zona de Compute Engine y el clúster de GKE antes de ejecutar kubectl:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/myimage', 'frontend=gcr.io/myproject/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east1-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image",
            "deployment/myimage",
            "frontend=gcr.io/myproject/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east1-b",
            "CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster"
        ]
    }
    ]
}

`dir`

Usa el campo dir de un paso de compilación para definir un directorio de trabajo que se usará al ejecutar el contenedor del paso. Si defines el campo dir en el paso de compilación, el directorio de trabajo se define como /workspace/<dir>. Si este valor es una ruta relativa, se refiere al directorio de trabajo de la compilación. Si este valor es absoluto, puede estar fuera del directorio de trabajo de la compilación, en cuyo caso el contenido de la ruta puede no conservarse en las ejecuciones de los pasos de compilación (a menos que se especifique un volumen para esa ruta).

En el siguiente fragmento de código se define el directorio de trabajo del paso de compilación como /workspace/examples/hello_world:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
  env: ['PROJECT_ROOT=hello']
  dir: 'examples/hello_world'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ],
        "env": [
            "PROJECT_ROOT=hello"
        ],
        "dir": "examples/hello_world"
    }
    ]
}

`timeout`

Usa el campo timeout en un paso de compilación para definir un límite de tiempo para ejecutar el paso. Si no defines este campo, el paso no tendrá límite de tiempo y se podrá ejecutar hasta que se complete o hasta que se agote el tiempo de espera de la compilación. El campo timeout de un paso de compilación no debe superar el valor timeout especificado para una compilación. timeout debe especificarse en segundos con hasta nueve dígitos fraccionarios y terminar con "s". Ejemplo: 3.5s

En la siguiente configuración de compilación, el paso ubuntu se agota al cabo de 500 segundos:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
  timeout: 500s
- name: 'ubuntu'
  args: ['echo', 'hello world, after 600s']

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ],
        "timeout": "500s"
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello world, after 600s"
        ]
    }
    ]
}

script

Usa el campo script en un paso de compilación para especificar una secuencia de comandos shell que se ejecutará en el paso. Si especificas script en un paso de compilación, no puedes especificar args ni entrypoint en el mismo paso. Para obtener instrucciones sobre cómo usar el campo script, consulta Ejecutar secuencias de comandos bash.

automapSubstitutions

Si se define como true, se asignarán automáticamente todas las sustituciones y se pondrán a disposición como variables de entorno en un solo paso. Si se define como false, se ignoran las sustituciones de ese paso. Para ver ejemplos, consulta Sustituir valores de variables.

ID

Usa el campo id para definir un identificador único para un paso de compilación. id se usa con el campo waitFor para configurar el orden en el que se deben ejecutar los pasos de la compilación. Para obtener instrucciones sobre cómo usar waitFor y id, consulta Configurar el orden de los pasos de compilación.

`waitFor`

Usa el campo waitFor en un paso de compilación para especificar qué pasos deben ejecutarse antes de que se ejecute el paso de compilación. Si no se proporcionan valores para waitFor, el paso de compilación espera a que se completen correctamente todos los pasos de compilación anteriores de la solicitud de compilación antes de ejecutarse. Para obtener instrucciones sobre cómo usar waitFor y id, consulta Configurar el orden de los pasos de compilación.

`entrypoint`

Usa entrypoint en un paso de compilación para especificar un punto de entrada si no quieres usar el punto de entrada predeterminado del compilador. Si no defines este campo, Cloud Build usará el punto de entrada del compilador. El siguiente fragmento define los puntos de entrada del paso de compilación npm:

YAML

steps:
- name: 'gcr.io/cloud-builders/npm'
  entrypoint: 'node'
  args: ['--version']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/npm",
        "entrypoint": "node",
        "args": [
            "--version"
        ]
    }
    ]
}

`secretEnv`

Lista de variables de entorno encriptadas con una clave criptográfica de Cloud KMS. Estos valores deben especificarse en los secretos de la compilación. Para obtener información sobre cómo usar este campo, consulta Usar la variable cifrada en las solicitudes de compilación.

`volumes`

Un volumen es un volumen de contenedor Docker que se monta en los pasos de compilación para conservar los archivos entre los pasos de compilación. Cuando Cloud Build ejecuta un paso de compilación, monta automáticamente un volumen workspace en /workspace. Puedes especificar volúmenes adicionales que se montarán en los contenedores de los pasos de compilación mediante el campo volumes de los pasos.

Por ejemplo, el siguiente archivo de configuración de compilación escribe un archivo en un volumen en el primer paso y lo lee en el segundo. Si en estos pasos no se especifica la ruta /persistent_volume como volumen persistente, en el primer paso se escribiría el archivo en esa ruta y, a continuación, se descartaría antes de que se ejecutara el segundo paso. Si especificas el volumen con el mismo nombre en ambos pasos, el contenido de /persistent_volume del primer paso se conservará en el segundo.

YAML

steps:
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
        echo "Hello, world!" > /persistent_volume/file
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  args: ['cat', '/persistent_volume/file']

JSON

  {
    "steps": [
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "entrypoint": "bash",
        "args": [
          "-c",
          "echo \"Hello, world!\" > /persistent_volume/file\n"
        ]
      },
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "args": [
          "cat",
          "/persistent_volume/file"
        ]
     }
    ]
  }

`allowFailure`

En un paso de compilación, si asignas el valor true al campo allowFailure y el paso de compilación falla, la compilación se realizará correctamente siempre que todos los demás pasos de compilación de esa compilación se completen correctamente.

Si todos los pasos de compilación de una compilación tienen el valor allowFailure definido como true y todos los pasos de compilación fallan, el estado de la compilación sigue siendo Successful.

allowExitCodes prevalece frente a este campo.

El siguiente fragmento de código permite que la compilación se realice correctamente cuando falla el primer paso:

YAML

steps:
- name: 'ubuntu'
  args: ['-c', 'exit 1']
  allowFailure: true
steps:
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit -1"
        ],
        "allowFailure": true,
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`allowExitCodes`

Usa el campo allowExitCodes para especificar que se puede ignorar un error de un paso de compilación cuando ese paso devuelva un código de salida concreto.

Si un paso de compilación falla con un código de salida que coincide con el valor que has proporcionado en allowExitCodes, Cloud Build permitirá que este paso de compilación falle sin que falle toda la compilación.

Si el 100% de los pasos de compilación fallan, pero cada paso finaliza con un código que has especificado en el campo allowExitCodes, la compilación se realizará correctamente.

Sin embargo, si el paso de compilación falla y produce otro código de salida (uno que no coincide con el valor que ha especificado en allowExitCodes), la compilación general fallará.

Los códigos de salida relevantes para tu compilación dependen de tu software. Por ejemplo, "1" es un código de salida habitual en Linux. También puedes definir tus propios códigos de salida en tus secuencias de comandos. El campo allowExitCodes acepta números de hasta 255.

Este campo tiene prioridad sobre allowFailure.

El siguiente fragmento de código permite que la compilación se complete correctamente cuando el primer paso falla con uno de los códigos de salida proporcionados:

YAML

steps:
- name: 'ubuntu'
  args: ['-c', 'exit 1']
  allowExitCodes: [1]
steps:
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit 1"
        ],
        "allowExitCodes": [1],
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`timeout`

Usa el campo timeout de una compilación para especificar el tiempo que se debe permitir que se ejecute la compilación, con una granularidad de segundos. Si transcurre este tiempo, se detendrá el trabajo en la compilación y el estado de la compilación será TIMEOUT. Si no se define timeout, se aplicará un valor predeterminado de 60 minutos a la compilación.timeout El valor máximo que se puede aplicar a timeout es de 24 horas. timeout debe especificarse en segundos con hasta nueve dígitos fraccionarios, que termina con "s". Ejemplo: 3.5s

En el siguiente fragmento, timeout se ha definido en 660 segundos para evitar que se agote el tiempo de espera de la compilación debido al tiempo de suspensión:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
timeout: 660s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ]
    }
    ],
    "timeout": "660s"
}

`queueTtl`

Usa el campo queueTtl para especificar el tiempo que puede estar en cola una compilación. Si una compilación permanece en la cola durante más tiempo que el valor definido en queueTtl, la compilación caduca y el estado de la compilación se define como EXPIRED. Si no se proporciona ningún valor, Cloud Build usa el valor predeterminado de 3600s (1 hora). queueTtl empieza a contar desde createTime. queueTtl debe especificarse en segundos con hasta nueve decimales, terminado por "s". Por ejemplo, 3.5s.

En el siguiente fragmento, timeout se ha definido como 20s y queueTtl como 10s. queueTtl empieza a contar a las createTime, que es la hora en la que se solicita la compilación, y timeout empieza a contar a las startTime, que es la hora en la que se inicia la compilación. Por lo tanto, queueTtl caducará a las createTime + 10s, a menos que la compilación se inicie antes.

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '5']
timeout: 20s
queueTtl: 10s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "5"
        ]
    }
    ],
    "timeout": "20s",
    "queueTtl": "10s"
}

`logsBucket`

Define el campo logsBucket de una compilación para especificar un segmento de Cloud Storage en el que se deben escribir los registros. Si no defines este campo, Cloud Build usará un segmento predeterminado para almacenar los registros de compilación.

El siguiente fragmento define un segmento de registros para almacenar los registros de compilación:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
logsBucket: 'gs://mybucket'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "logsBucket": "gs://mybucket"
}

`options`

Usa el campo options para especificar los siguientes argumentos opcionales de tu compilación:

enableStructuredLogging: habilita la asignación de los campos de registro de compilación especificados a los campos LogEntry cuando el registro de compilación se envía a Logging. Por ejemplo, si tu registro de compilación contiene un message, el mensaje aparecerá en textPayload o jsonPayload.message en la entrada de registro resultante. Los campos de registro de compilación que no se pueden asignar aparecen en la entrada de registro jsonPayload. Para obtener más información, consulta el artículo sobre cómo asignar campos de registro de compilación a campos de entrada de registro.

env: una lista de definiciones de variables de entorno globales que estarán disponibles para todos los pasos de compilación de esta compilación. Si una variable se define tanto de forma global como en un paso de compilación, la variable usará el valor del paso de compilación. Los elementos tienen el formato KEY=VALUE, donde la variable de entorno KEY recibe el valor VALUE.

secretEnv: una lista de variables de entorno globales, cifradas con una clave criptográfica de Cloud Key Management Service, que estarán disponibles para todos los pasos de compilación de esta compilación. Estos valores deben especificarse en el Secret de la compilación.

volumes: Lista de volúmenes que se montarán de forma global en TODOS los pasos de compilación. Cada volumen se crea como un volumen vacío antes de iniciar el proceso de compilación. Una vez completada la compilación, se descartan los volúmenes y su contenido. Los nombres y las rutas de los volúmenes globales no pueden entrar en conflicto con los volúmenes definidos en un paso de compilación. No se puede usar un volumen global en una compilación con un solo paso, ya que significa que se ha enviado una solicitud de compilación con una configuración incorrecta.

pubsubTopic: opción para proporcionar un nombre de tema de Pub/Sub para recibir notificaciones de estado de compilación. Si no proporcionas un nombre, Cloud Build usará el nombre de tema predeterminado cloud-builds. El siguiente fragmento especifica que el nombre del tema de Pub/Sub es my-topic:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    pubsubTopic: 'projects/my-project/topics/my-topic'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "pubsubTopic": "projects/my-project/topics/my-topic"
    }
}

sourceProvenanceHash: define la opción sourceProvenanceHash para especificar el algoritmo de hash de la procedencia de la fuente. En el siguiente fragmento se especifica que el algoritmo hash es SHA256:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    sourceProvenanceHash: ['SHA256']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "sourceProvenanceHash": ["SHA256"]
    }
}

machineType: Cloud Build ofrece cuatro tipos de máquinas virtuales con alta capacidad de CPU para ejecutar tus compilaciones: dos tipos de máquinas con 8 CPUs y dos tipos de máquinas con 32 CPUs. Cloud Build también ofrece dos tipos de máquinas virtuales adicionales con 1 y 2 CPUs para ejecutar tus compilaciones. El tipo de máquina predeterminado es e2-standard-2 con 2 CPUs. Si solicitas una máquina virtual con una CPU de alto rendimiento, es posible que aumente el tiempo de inicio de tu compilación. Añade la opción machineType para solicitar una máquina virtual con una CPU más potente:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 machineType: 'E2_HIGHCPU_8'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    ],
    "options": {
        "machineType": "E2_HIGHCPU_8"
    }
}

Para obtener más información sobre cómo usar la opción machineType, consulta Acelerar las compilaciones.

diskSizeGb: Usa la opción diskSizeGb para solicitar un tamaño de disco personalizado para tu compilación. El tamaño máximo que puedes solicitar es de 4000 GB.

En el siguiente fragmento se solicita un tamaño de disco de 200 GB:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 diskSizeGb: '200'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "diskSizeGb": '200'
    }
}

logStreamingOption: utiliza esta opción para especificar si quieres enviar los registros de compilación a Cloud Storage. De forma predeterminada, Cloud Build recoge los registros de compilación cuando se completa la compilación. Esta opción especifica si quieres transmitir los registros de compilación en tiempo real durante el proceso de compilación. El siguiente fragmento especifica que los registros de compilación se transmiten a Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
options:
 logStreamingOption: STREAM_ON

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "options": {
        "logStreamingOption": "STREAM_ON"
    }
}

logging: Usa esta opción para especificar si quieres almacenar los registros en Cloud Logging o en Cloud Storage. Si no lo haces, Cloud Build almacenará los registros en Cloud Logging y Cloud Storage. Puedes definir la opción logging en GCS_ONLY para almacenar los registros solo en Cloud Storage. El siguiente fragmento especifica que los registros se almacenan en Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 logging: GCS_ONLY

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "logging": "GCS_ONLY"
    }
}

defaultLogsBucketBehavior: La opción defaultLogsBucketBehavior te permite configurar Cloud Build para que cree un segmento de registro predeterminado en tu proyecto, en la misma región que tu compilación. Para obtener más información, consulta Almacenar registros de compilación en un segmento regionalizado propiedad del usuario.

La siguiente configuración de compilación asigna el valor REGIONAL_USER_OWNED_BUCKET al campo defaultLogsBucketBehavior:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
options:
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
        "."
      ]
    }
    ],
    "options": {
      "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
    }
}

dynamicSubstitutions: usa esta opción para habilitar o inhabilitar explícitamente la expansión de parámetros bash en las sustituciones. Si tu compilación se invoca mediante un activador, el campo dynamicSubstitutions siempre se define como true y no es necesario especificarlo en el archivo de configuración de la compilación. Si la compilación se invoca manualmente, debes definir el campo dynamicSubstitutions como true para que las expansiones de parámetros de bash se interpreten al ejecutar la compilación.

automapSubstitutions: Asigna automáticamente todas las sustituciones a variables de entorno que estarán disponibles durante todo el proceso de compilación. Para ver ejemplos, consulta Sustituir valores de variables.

substitutionOption: Esta opción se configura junto con el campo substitutions de abajo para especificar el comportamiento cuando se produce un error en las comprobaciones de sustitución.

pool: Define el valor de este campo como el nombre del recurso del grupo privado para ejecutar la compilación. Para obtener instrucciones sobre cómo ejecutar una compilación en un grupo privado, consulta el artículo Ejecutar compilaciones en un grupo privado.

requestedVerifyOption: Asigna el valor VERIFIED a requestedVerifyOption para habilitar y verificar la generación de atestaciones y metadatos de procedencia de tu compilación. Una vez configurado, tus compilaciones solo se marcarán como SUCCESS si se generan atestaciones y procedencia.

`substitutions`

Usa sustituciones en el archivo de configuración de compilación para sustituir variables específicas en el momento de la compilación. Las sustituciones son útiles para las variables cuyo valor no se conoce hasta el momento de la compilación o para reutilizar una solicitud de compilación con diferentes valores de variable. De forma predeterminada, la compilación devuelve un error si falta una variable de sustitución o una sustitución. Sin embargo, puedes usar la opción ALLOW_LOOSE para saltarte esta comprobación.

En el siguiente fragmento se usan sustituciones para imprimir "hello world.". Se ha definido la opción de sustitución ALLOW_LOOSE, lo que significa que la compilación no devolverá un error si falta una variable de sustitución o una sustitución.

YAML

steps:
- name: 'ubuntu'
  args: ['echo', 'hello ${_SUB_VALUE}']
substitutions:
    _SUB_VALUE: world
options:
    substitution_option: 'ALLOW_LOOSE'

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello ${_SUB_VALUE}"
        ]
    }
    ],
    "substitutions": {
        "_SUB_VALUE": "world"
},
    "options": {
        "substitution_option": "ALLOW_LOOSE"
    }
}

Para obtener más instrucciones sobre cómo usar substitutions, consulta Sustituir valores de variables.

`tags`

Usa el campo tags para organizar tus compilaciones en grupos y filtrarlas. La siguiente configuración define dos etiquetas llamadas mytag1 y mytag2:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  ...
- name: 'ubuntu'
  ...
tags: ['mytag1', 'mytag2']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker"
    },
    {
        "name": "ubuntu"
    }
    ],
    "tags": [
        "mytag1",
        "mytag2"
    ]
}

`availableSecrets`

Usa este campo para usar un secreto de Secret Manager con Cloud Build. Para obtener más información, consulta Usar secretos.

`secrets`

Secret empareja un conjunto de variables de entorno secretas que contienen valores cifrados con la clave de Cloud KMS que se debe usar para descifrar el valor.

`serviceAccount`

Usa este campo para especificar la cuenta de servicio de gestión de identidades y accesos que se va a usar en el momento de la compilación. Para obtener más información, consulta el artículo sobre cómo configurar cuentas de servicio especificadas por los usuarios.

No puedes especificar la cuenta de servicio antigua de Cloud Build en este campo.

`images`

El campo images del archivo de configuración de la compilación especifica una o varias imágenes de Docker de Linux que Cloud Build debe enviar a Artifact Registry. Puede que tengas una compilación que realice tareas sin generar ninguna imagen Docker de Linux, pero si compilas imágenes y no las envías al registro, se descartarán cuando se complete la compilación. Si no se genera una imagen específica durante la compilación, esta fallará. Para obtener más información sobre cómo almacenar imágenes, consulta el artículo Almacenar artefactos en Artifact Registry.

La siguiente configuración de compilación asigna el campo images para almacenar la imagen compilada:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
images: ['gcr.io/myproject/myimage']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "images": [
        "gcr.io/myproject/myimage"
    ]
}

`artifacts`

El campo artifacts del archivo de configuración de compilación especifica uno o varios artefactos que no son contenedores y que se almacenarán en Cloud Storage. Para obtener más información sobre cómo almacenar artefactos que no son de contenedor, consulta Almacenar artefactos de compilación en Cloud Storage.

La siguiente configuración de compilación asigna el campo artifacts para almacenar el paquete Go compilado en gs://mybucket/:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['build', 'my-package']
artifacts:
  objects:
    location: 'gs://mybucket/'
    paths: ['my-package']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "build",
            "my-package"
        ]
    }
    ],
    "artifacts": {
      "objects": {
        "location": "gs://mybucket/",
        "paths": [
            "my-package"
        ]
      }
    }
}

`goModules`

El campo goModules te permite subir módulos Go que no sean contenedores a repositorios Go en Artifact Registry. Para obtener más información, consulta el artículo Compilar y probar aplicaciones Go.

El campo repository_location especifica el repositorio de Artifact Registry en el que se almacenarán tus paquetes. El campo module_path especifica el directorio local que contiene el módulo de Go que se va a subir. Este directorio debe contener un archivo go.mod.

Te recomendamos que uses una ruta absoluta para el valor de module_path. Puedes usar . para hacer referencia al directorio de trabajo actual, pero el campo no se puede omitir ni dejar vacío. Para obtener más instrucciones sobre cómo usar module_path, consulta Desarrollar y probar aplicaciones de Go.

La siguiente configuración de compilación asigna el valor goModules al campo para subir el módulo en example.com/myapp al repositorio quickstart-go-repo de Artifact Registry:

YAML

artifacts:
  goModules:
    - repositoryName: 'quickstart-go-repo'
      repositoryLocation: 'us-central1'
      repositoryProjectId: 'argo-local-myname'
      sourcePath: '/workspace/myapp'
      modulePath: 'example.com/myapp'
      moduleVersion: 'v1.0.0'

JSON

{
  "artifacts": {
    "goModules": [
     {
      "repositoryName": "quickstart-go-repo",
      "repositoryLocation": "us-central1",
      "repositoryProjectId": "argo-local-myname",
      "sourcePath": "/workspace/myapp",
      "modulePath": "example.com/myapp",
      "moduleVersion": "v1.0.0"
     }
    ]
  }
}

`mavenArtifacts`

El campo mavenArtifacts te permite subir artefactos de Java que no sean contenedores a repositorios de Maven en Artifact Registry. Para obtener más información, consulta Desarrollar y probar aplicaciones Java.

La siguiente configuración de compilación asigna el valor mavenArtifacts al campo para subir el archivo empaquetado my-app-1.0-SNAPSHOT.jar al repositorio https://us-central1-maven.pkg.dev/my-project-id/my-java-repo de Artifact Registry:

YAML

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      path: '/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar'
      artifactId: 'my-app-1'
      groupId: 'com.mycompany.app'
      version: '1.0.0'

JSON

{
  "artifacts": {
    "mavenArtifacts": [
      {
        "repository": "https://us-central1-maven.pkg.dev/my-project-id/my-java-repo",
        "path": "/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

`pythonPackages`

El campo pythonPackages le permite subir paquetes de Python a Artifact Registry. Para obtener más información, consulta Compilar y probar aplicaciones de Python.

La siguiente configuración de compilación asigna el valor pythonPackages al campo para subir el paquete de Python dist/my-pkg.whl al repositorio https://us-east1-python.pkg.dev/my-project/my-repo de Artifact Registry:

YAML

artifacts:
  pythonPackages:
   - repository: 'https://us-east1-python.pkg.dev/my-project/my-repo'
     paths: ['dist/my-pkg.whl']

JSON

{
  "artifacts": {
    "pythonPackages": [
      {
        "repository": "https://us-east1-python.pkg.dev/my-project/my-repo",
        "paths": ["dist/my-pkg.whl"]
      }
    ]
  }
}

`npmPackages`

Usa el campo npmPackages para configurar Cloud Build de forma que suba los paquetes npm compilados a los repositorios admitidos de Artifact Registry. Debes proporcionar valores para repository y packagePath.

El campo repository especifica el repositorio de Artifact Registry en el que se almacenarán tus paquetes. El campo packagePath especifica el directorio local que contiene el paquete npm que se va a subir. Este directorio debe contener un archivo package.json.

Te recomendamos que uses una ruta absoluta para el valor de packagePath. Puedes usar . para hacer referencia al directorio de trabajo actual, pero el campo no se puede omitir ni dejar vacío. Para obtener más instrucciones sobre cómo usar npmPackages, consulta Crear y probar aplicaciones de Node.js.

La siguiente configuración de compilación asigna el valor npmPackages al campo para subir el paquete npm del directorio /workspace/my-pkg al repositorio de Artifact Registry https://us-east1-npm.pkg.dev/my-project/my-repo.

YAML

artifacts:
  npmPackages:
   - repository: 'https://us-east1-npm.pkg.dev/my-project/my-repo'
     packagePath: '/workspace/my-pkg'

JSON

{
  "artifacts": {
    "npmPackages": [
      {
        "repository": "https://us-east1-npm.pkg.dev/my-project/my-repo",
        "packagePath": "/workspace/my-pkg"
      }
    ]
  }
}

Usar Dockerfiles

Si ejecutas compilaciones de Docker en Cloud Build con gcloud CLI o activadores de compilación, puedes usar un Dockerfile sin un archivo de configuración de compilación independiente. Si quieres hacer más ajustes en tus compilaciones de Docker, puedes proporcionar un archivo de configuración de compilación además del Dockerfile. Para obtener instrucciones sobre cómo crear una imagen Docker mediante un Dockerfile, consulta la guía de inicio rápido sobre compilación.

Red de Cloud Build

Cuando Cloud Build ejecuta cada fase de compilación, adjunta el contenedor de la fase a una red Docker local llamada cloudbuild. La cloudbuild red aloja credenciales de aplicación predeterminadas (ADC) que los Google Cloud servicios pueden usar para encontrar automáticamente tus credenciales. Si ejecutas contenedores Docker anidados y quieres exponer el ADC a un contenedor subyacente o usar gcloud en un paso docker, usa la marca --network en el paso build de Docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '--network=cloudbuild', '.']

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "--network=cloudbuild",
        "."
      ]
   }
  ]
}

Siguientes pasos

Consulta cómo crear un archivo de configuración de compilación básico para configurar compilaciones en Cloud Build.
Consulta Iniciar una compilación manualmente para obtener instrucciones sobre cómo ejecutar compilaciones en Cloud Build.

Esquema del archivo de configuración de compilación Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Estructura de un archivo de configuración de compilación

YAML

JSON

Fases de compilación

YAML

JSON

name

YAML

JSON

args

YAML

JSON

env

YAML

JSON

dir

YAML

JSON

timeout

YAML

JSON

script

automapSubstitutions

ID

waitFor

entrypoint

YAML

JSON

secretEnv

volumes

YAML

JSON

allowFailure

YAML

JSON

allowExitCodes

YAML

JSON

timeout

YAML

JSON

queueTtl

YAML

JSON

logsBucket

YAML

JSON

options

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

YAML

JSON

substitutions

YAML

JSON

tags

YAML

JSON

availableSecrets

secrets

serviceAccount

images

YAML

JSON

artifacts

YAML

JSON

goModules

YAML

Esquema del archivo de configuración de compilación

`name`

`args`

`env`

`dir`

`timeout`

`waitFor`

`entrypoint`

`secretEnv`

`volumes`

`allowFailure`

`allowExitCodes`

`timeout`

`queueTtl`

`logsBucket`

`options`

`substitutions`

`tags`

`availableSecrets`

`secrets`

`serviceAccount`

`images`

`artifacts`

`goModules`

`mavenArtifacts`

`pythonPackages`

`npmPackages`