Esquema del archivo de configuración de compilación

Los archivos de configuración de compilación contienen instrucciones para que Cloud Build realice tareas en función de tus especificaciones. Por ejemplo, el archivo de configuración de compilación puede contener instrucciones para compilar, enviar y empaquetar imágenes de 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 Crea un archivo de configuración de compilación básico.

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 compilación con la sintaxis de YAML o JSON. Si envías solicitudes de compilación mediante herramientas http de terceros como curl, usa la sintaxis de 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
  results: object(Results)
- 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)
 workerRelease: string
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",
        "results": "object(Results)"
    },
    {
        "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)",
        "pubsubTopic: string",
        "requestedVerifyOption": "enum(RequestedVerifyOption)",
        "workerRelease": "string"
    },
    "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",
        "..."
    ]
}

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

Pasos de la compilación

Un paso de compilación especifica una acción que deseas que realice Cloud Build. Para cada paso de compilación, Cloud Build ejecuta un contenedor de Docker como una instancia de docker run. Los pasos de la compilación son similares a los comandos en una secuencia de comandos y te proporcionan 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 en serie en la misma máquina. Si tienes pasos que pueden ejecutarse en simultáneo, usa la opción waitFor.

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

Usa el campo steps en el archivo de configuración de compilación para especificar un paso de compilación. A continuación, se muestra un fragmento del tipo de configuración que puedes establecer 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 compilador en la nube, que es una imagen de contenedor que ejecuta herramientas comunes. Debes usar un compilador en un paso de compilación para ejecutar tus tareas.

En el siguiente fragmento, se muestran los pasos de compilación mediante los cuales se llaman a los compiladores de 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 pasa al compilador al que hace referencia el campo name. Los argumentos que se pasan al compilador se pasan a la herramienta que se ejecuta en el compilador, lo que te permite invocar cualquier comando que admita la herramienta. Si el compilador usado en el paso de compilación tiene un punto de entrada, se usará args como argumentos para ese punto de entrada. Si el compilador no define un punto de entrada, el primer elemento en args se usará como punto de entrada y el resto se usará como argumento.

Puedes crear hasta 100 argumentos por paso. La longitud máxima del argumento es de 10,000 caracteres.

En el siguiente fragmento, se invoca el comando docker build y, luego, se instalan 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 las variables de entorno que se usarán cuando se ejecute el paso. Las variables tienen la forma KEY=VALUE.

En la siguiente configuración de compilación, en el campo env del paso de compilación, se establecen 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"
        ]
    }
    ]
}

allowFailure

En un paso de compilación, si estableces el valor del campo allowFailure en true y el paso de compilación falla, la compilación se realizará correctamente, siempre y cuando todos los demás pasos de compilación de esa compilación se realicen correctamente.

Si todos los pasos de una compilación tienen allowFailure configurado como true y todos fallan, el estado de la compilación seguirá siendo Successful.

allowExitCodes tiene prioridad sobre 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
- 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 en un paso de compilación cuando ese paso devuelve un código de salida específico.

Si un paso de compilación falla con un código de salida que coincide con el valor que proporcionaste 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 se cierra con un código que especificaste en el campo allowExitCodes, la compilación se realiza correctamente.

Sin embargo, si el paso de compilación falla y produce otro código de salida, uno que no coincida con el valor que especificaste 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 común en Linux. También puedes definir tus propios códigos de salida en tus secuencias de comandos. El campo allowExitCodes acepta números hasta un máximo de 255.

Este campo tiene prioridad sobre allowFailure.

El siguiente fragmento de código permite que la compilación se realice 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]
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON 

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

dir

Usa el campo dir en un paso de compilación para establecer un directorio de trabajo que se usará cuando se ejecute el contenedor del paso. Si configuras el campo dir en el paso de compilación, el directorio de trabajo se establece en /workspace/<dir>. Si este valor es una ruta relativa, es relativa 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 es posible que el contenido de la ruta de acceso no se conserve en las ejecuciones de los pasos de compilación (a menos que se especifique un volumen para esa ruta de acceso).

En el siguiente fragmento de código, se establece el directorio de trabajo para el 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"
    }
    ]
}

ID

Usa el campo id a fin de establecer un identificador único para un paso de compilación. id se usa con el campo waitFor para establecer el orden en el que se deben ejecutar los pasos de compilación. A fin de obtener instrucciones para usar id y waitFor, consulta Configura el orden de los pasos de compilación.

waitFor

Usa el campo waitFor del paso de compilación para especificar qué pasos se deben ejecutar antes que dicho paso. Si no se proporciona ningún valor en waitFor, el paso de compilación no se ejecutará hasta que todos los pasos de compilación de la solicitud de compilación se completen de manera correcta. A fin de obtener instrucciones para usar id y waitFor, consulta Configura 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 predeterminado del compilador. Si no configuras este campo, Cloud Build usará el punto de entrada del compilador. En el siguiente fragmento, se establecen los puntos de entrada para el 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

Se trata de una lista de variables de entorno que se encriptan con una clave criptográfica de Cloud KMS. Estos valores se deben especificar en los secretos de la compilación. Para obtener información sobre el uso de este campo, consulta Uso de la variable encriptada en las solicitudes de compilación.

volumes

Un Volume es un volumen de contenedor de Docker que se activa en los pasos de compilación para conservar los archivos en todos los pasos de compilación. Cuando Cloud Build ejecuta un paso de compilación, se activa un volumen workspace en /workspace de forma automática. Se pueden especificar volúmenes adicionales para que se activen en los contenedores de los pasos de compilación mediante el campo volumes de tus 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 paso. Si en estos pasos no se especificó la ruta de acceso /persistent_volume como un volumen persistente, el archivo se escribirá en esa ruta en el primer paso y se descartará antes de que se ejecute el segundo paso. Cuando se especifica el volumen con el mismo nombre en ambos pasos, el contenido de /persistent_volume del primer paso se conserva 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"
        ]
     }
    ]
  }

timeout

Usa el campo timeout en un paso de compilación a fin de establecer un límite de tiempo para ejecutar el paso. Si no configuras este campo, el paso se ejecuta hasta que se completa o hasta que se agota 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 la compilación.

timeout se especifica en segundos (con el formato Duration) con hasta nueve dígitos decimales, que terminan en s (por ejemplo: 3.5s).

En la siguiente configuración de compilación, se agota el tiempo de espera del paso ubuntu después 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 de 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 Ejecuta secuencias de comandos de Bash.

automapSubstitutions

Si se establece en true, asigna automáticamente todas las sustituciones y haz que estén disponibles como variables de entorno en un solo paso. Si se establece en false, se ignoran las sustituciones para ese paso. Para ver ejemplos, consulta Sustituye valores de variables.

resultados

Permite que un paso de compilación almacene datos y, luego, los adjunte en una certificación dentro de los resultados de la compilación después de que esta se complete. Los datos almacenados deben ser un par clave-valor, en el que la clave es una cadena y el valor es un objeto JSON. Un resultado debe tener los siguientes campos:

  • name: Es el nombre del resultado. Este nombre aparece en la certificación resultante dentro de los resultados de la compilación. También puedes usar este nombre para hacer referencia al resultado en un paso de compilación. Por ejemplo, puedes agregar valores al resultado con un script en el mismo paso de compilación.
  • attestationContent: (Opcional) Es el nombre de la certificación. Puede ser cualquier valor y aparecerá en la certificación resultante dentro de los resultados de la compilación. Este campo solo es necesario si planeas validar tus certificaciones de compilación.
  • attestationType: Es el tipo de certificación (opcional). Puede ser cualquier valor y aparecerá en la certificación resultante dentro de los resultados de la compilación. Este campo solo es necesario si planeas validar tus certificaciones de compilación.

En la siguiente compilación, se usa una configuración de resultados para generar una certificación que permita a los usuarios verificar que la compilación solo usó URLs con prefijos admitidos para compilar la imagen. En este ejemplo, un resultado se define como allowlisted_prefixes. Luego, allowlisted_prefixes se establece como el par clave-valor de allowlisted_prefixes y [\"github.com\", \"gitlab.com\"], y, luego, se adjunta como una certificación a los resultados de la compilación.

YAML 

steps:
- name: "gcr.io/cloud-builders/docker"
  id: "build-step"
  args: ["build", "-t", "us-docker.pkg.dev/my-project/demo/helloworld-image", "."]
- name: "ubuntu"
  id: "check-source-fetch-urls"
  results:
    - name: "allowlisted_prefixes"
      attestationContent: "remote_fetch_allow_list"
      attestationType: "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
  script: |
    #!/bin/bash
    prefixes="[\"github.com\", \"gitlab.com\"]"
    echo "allowlisted_prefixes=$prefixes" >> $RESULTS
    cat $RESULTS
images:
  - "us-docker.pkg.dev/my-project/demo/helloworld-image"
options:
  requested_verify_option: VERIFIED
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON 

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "id": "build-step",
      "args": [
        "build",
        "-t",
        "us-docker.pkg.dev/my-project/demo/helloworld-image",
        "."
      ]
    },
    {
      "name": "ubuntu",
      "id": "check-source-fetch-urls",
      "results": [
        {
          "name": "allowlisted_prefixes",
          "attestationContent": "remote_fetch_allow_list",
          "attestationType": "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
        }
      ],
      "script": "#!/bin/bash\nprefixes=\"[\\\"github.com\\\", \\\"gitlab.com\\\"]\"\necho \"allowlisted_prefixes=$prefixes\" >> $RESULTS\ncat $RESULTS\n"
    }
  ],
  "images": [
    "us-docker.pkg.dev/my-project/demo/helloworld-image"
  ],
  "options": {
    "requested_verify_option": "VERIFIED",
    "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
  }
}

timeout

Usa el campo timeout fuera de un paso de compilación para establecer el límite de tiempo general para ejecutar la compilación. Si transcurre este tiempo, se detiene el trabajo en la compilación y el estado de la compilación es TIMEOUT.

Si no se establece timeout, la compilación usa un timeout predeterminado de 60 minutos. El valor máximo de timeout es 24 horas. timeout se especifica en segundos, con el formato Duration, con hasta nueve dígitos decimales, que terminan en s (por ejemplo: 3.5s).

En el siguiente fragmento, timeout se establece en 660 segundos para evitar que la compilación agote el tiempo de espera debido a una 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 la cantidad de tiempo que se puede poner en cola una compilación. Si una compilación está en la cola por más tiempo que el valor establecido en queueTtl, la compilación vence y el estado de la compilación se establece en EXPIRED. Si no se proporciona ningún valor, Cloud Build usa el valor predeterminado de 3600s (1 hora). queueTtl comienza a correr a partir del createTime. queueTtl se debe especificar en segundos con hasta nueve dígitos decimales, terminados en "s", por ejemplo, 3.5s.

En el siguiente fragmento, timeout se establece en 20s y queueTtl se establece en 10s. queueTtl comienza a contar en createTime, que es el momento en que se solicita la compilación, y timeout comienza a contar en startTime, que es el momento en que se inicia la compilación. Por lo tanto, queueTtl vencerá el createTime + 10s, a menos que la compilación comience para ese momento.

YAML 

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

JSON 

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

logsBucket

Establece el campo logsBucket de una compilación para especificar un bucket de Cloud Storage en el que se deben escribir los registros de compilación. Si no configuras este campo, Cloud Build usa el valor de defaultLogsBucketBehavior para almacenar tus registros de compilación en un bucket creado por Cloud Build en Cloud Storage.

En el siguiente fragmento, se configura Cloud Build para almacenar registros de compilación en un bucket personalizado en Cloud Storage.

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 a fin de especificar los siguientes optionsargumentos opcionales para la compilación:

enableStructuredLogging: Habilita la asignación de los campos de registro de compilación especificados a los campos de 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 aparece 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 Asigna campos de registro de compilación a campos de entrada de registro.

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

secretEnv: Es una lista de variables de entorno globales, encriptadas con una clave de encriptación de Cloud Key Management Service, que estarán disponibles para todos los pasos de compilación de esta compilación. Estos valores se deben especificar en el Secret de la compilación.

volumes: Lista de volúmenes para activar en TODOS los pasos de compilación a nivel global. Cada volumen se crea como un volumen vacío antes de comenzar el proceso de compilación. Una vez que finaliza la compilación, los volúmenes y sus contenidos se descartan. Los nombres y las rutas de acceso de los volúmenes globales no pueden entrar en conflicto con los volúmenes definidos en un paso de compilación. El uso de un volumen global en una compilación con un solo paso no es válido, ya que significa 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 la compilación. Si no proporcionas un nombre, Cloud Build usa el nombre de tema predeterminado de cloud-builds. En el siguiente fragmento, se 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: Establece la opción sourceProvenanceHash a fin de especificar el algoritmo hash para 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 proporciona cuatro máquina virtual con alta capacidad de CPU para ejecutar tus compilaciones: dos tipos de máquinas con 8 CPU y dos tipos de máquinas con 32 CPU. Cloud Build también proporciona dos tipos de máquina virtual adicionales con 1 CPU y 2 CPU para ejecutar tus compilaciones. El tipo de máquina predeterminado es e2-standard-2 con 2 CPUs. Solicitar una máquina virtual con alta capacidad de CPU puede aumentar el tiempo de inicio de tu compilación. Agrega la opción machineType para solicitar una máquina virtual con una capacidad de CPU más alta:

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 el uso de la opción machineType, consulta Acelera tus compilaciones.

diskSizeGb: Usa la opción diskSizeGb a fin de solicitar un tamaño de disco personalizado para la compilación. El tamaño máximo que puedes solicitar es de 4,000 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: Usa esta opción para especificar si deseas transmitir los registros de compilación a Cloud Storage. De forma predeterminada, Cloud Build recopila los registros de compilación cuando finaliza la compilación; esta opción especifica si deseas transmitir los registros de compilación en tiempo real a través del proceso de compilación. En el siguiente fragmento, se 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 de compilación en Cloud Logging o Cloud Storage:

  • GCS_ONLY: Los registros de compilación se envían a los buckets de Cloud Storage.
  • CLOUD_LOGGING_ONLY: Los registros de compilación se envían a los buckets de Logging.
  • LEGACY: Los registros de compilación se envían a los buckets de ambas ubicaciones. Si logging no está definido, Cloud Build usa este valor.
  • NONE: No se almacenan los registros de compilación.

Para obtener más información sobre los beneficios y las consideraciones del almacenamiento de registros de compilación, consulta Opciones de almacenamiento de registros de compilación.

En el siguiente fragmento, se especifica que los registros de compilación 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:

Usa este campo cuando logging esté configurado para enviar tus registros de compilación a Cloud Storage.

Cuando logging tiene un valor de GCS_ONLY, Legacy o no está definido, tus registros de compilación se envían a buckets en Cloud Storage. En este caso, Cloud Build evalúa los campos logsBucket y defaultLogsBucketBehavior para determinar qué bucket de Cloud Storage recibe tus registros de compilación:

logsBucket defaultLogsBucketBehavior Dónde se almacenan los registros de compilación
Bucket especificado Se ignoró el valor En el bucket especificado en logsBucket
Sin valor REGIONAL_USER_OWNED_BUCKET En un bucket creado por Cloud Build y que pertenece al usuario
Sin valor LEGACY_BUCKET En un bucket creado por Cloud Build y propiedad de Google Cloud
Sin valor Sin valor En un bucket creado por Cloud Build y que pertenece al usuario Si no se puede crear este bucket, los registros de compilación se almacenan en un bucket creado por Cloud Build y propiedad de Google Cloud.

Para obtener más información, consulta Opciones de almacenamiento de registros de compilación.

La siguiente configuración de compilación establece el campo defaultLogsBucketBehavior en el valor REGIONAL_USER_OWNED_BUCKET:

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 de forma explícita la expansión de parámetros de Bash en las sustituciones. Si un activador invoca tu compilación, el campo dynamicSubstitutions siempre se establece como verdadero y no es necesario especificarlo en el archivo de configuración de compilación. Si tu compilación se invoca de forma manual, debes establecer el campo dynamicSubstitutions como verdadero para que las expansiones de parámetros de Bash se interpreten cuando se ejecute la compilación.

automapSubstitutions: Asigna automáticamente todas las sustituciones a las variables de entorno que estarán disponibles durante toda la compilación. Para ver ejemplos, consulta Sustituye los valores de las variables.

substitutionOption: Establecerás esta opción, junto con el campo substitutions que se encuentra a continuación, para especificar el comportamiento cuando hay un error en las verificaciones de sustitución.

pool: Establece el valor de este campo en 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 Ejecuta compilaciones en un grupo privado.

requestedVerifyOption: Establece el valor de requestedVerifyOption en VERIFIED para habilitar y verificar la generación de certificaciones y metadatos de procedencia para tu compilación. Una vez que se establezca, tus compilaciones solo se marcarán como SUCCESS si se generan certificaciones y procedencia.

workerRelease: Elige un canal de versiones o una versión específica.

En la siguiente configuración de compilación, se establece el campo workerRelease en el canal regular:

YAML 

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

JSON 

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

En el siguiente ejemplo, se establece el campo workerRelease en una versión específica:

YAML 

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

JSON 

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

substitutions

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

En el siguiente fragmento, se usan sustituciones para imprimir “hello world”. La opción de sustitución ALLOW_LOOSE está establecida, lo que significa que la compilación no mostrará un error si falta una sustitución o una variable de 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 instrucciones adicionales sobre el uso de substitutions, consulta Sustituye valores de variables.

tags

Usa el campo tags para organizar tus compilaciones en grupos y filtrarlas. Mediante la siguiente configuración, se establecen dos etiquetas con el nombre 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 hacer referencia a uno o más secretos de Secret Manager o Cloud KMS en tu solicitud de compilación. Cloud Build puede usar esos secretos para realizar una acción durante el proceso de compilación, como acceder a una cuenta.

Secret Manager

Para usar los secretos de Secret Manager en tu archivo de configuración de compilación, agrega un campo secretManager al campo availableSecrets en tu archivo de configuración de compilación. El campo secretManager contiene uno o más pares de los campos versionName y env:

  • versionName: Es la ruta de acceso al Secret en Secret Manager.
  • env: Es un nombre local (variable de entorno) que los pasos de compilación pueden usar para hacer referencia al Secret.

El campo secretEnv de un paso de compilación especifica qué variables de entorno se pueden usar en ese paso.

En la siguiente configuración, se muestra cómo acceder a Docker con un nombre de usuario y una contraseña de Docker almacenados en Secret Manager:

YAML 

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      entrypoint: 'bash'
      args: ['-c', 'docker login --username=$$USERNAME --password=$$PASSWORD']
      secretEnv: ['USERNAME', 'PASSWORD']
    availableSecrets:
      secretManager:
      - versionName: projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION
        env: 'PASSWORD'
      - versionName: projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION
        env: 'USERNAME'

JSON 

{
  "steps": [
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker login --username=$$USERNAME --password=$$PASSWORD"
    ],
    "secretEnv": [
      "USERNAME",
      "PASSWORD"
    ]
  }
  ],
  "availableSecrets": {
    "secretManager": [{
      "versionName": "projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION",
      "env": "PASSWORD"
  }, {
    "versionName": "projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION",
    "env": "USERNAME"
      }]
  }
}

Para obtener más información, consulta Usa Secrets.

Cloud KMS

Para usar claves de Cloud KMS en tu archivo de configuración de compilación, agrega un campo inline al campo availableSecrets en tu archivo de configuración de compilación. El campo inline contiene uno o más pares de kmsKeyName y envMap:

  • kmsKeyName: Es la ruta de acceso a la clave de Cloud KMS.
  • envMap: un nombre local (asignación de entorno) que los pasos de compilación pueden usar para hacer referencia al Secret.

El campo secretEnv de un paso de compilación especifica qué variables de entorno se pueden usar en ese paso.

En la siguiente configuración, se muestra cómo acceder a Docker con un nombre de usuario y una contraseña de Docker almacenados en Cloud KMS.

YAML

     steps:
     - name: 'gcr.io/cloud-builders/docker'
       entrypoint: 'bash'
       args: ['-c', 'docker login --username=$$USERNAME --password=$$PASSWORD']
       secretEnv: ['USERNAME', 'PASSWORD']
     - name: 'gcr.io/cloud-builders/docker'
       entrypoint: 'bash'
       args: ['-c', 'docker pull $$USERNAME/IMAGE:TAG']
       secretEnv: ['USERNAME']
     availableSecrets:
       inline:
       - kmsKeyName: projects/PROJECT_ID/locations/global/keyRings/USERNAME_KEYRING_NAME/cryptoKeys/USERNAME_KEY_NAME
         envMap:
           USERNAME: 'ENCRYPTED_USERNAME'
       - kmsKeyName: projects/PROJECT_ID/locations/global/keyRings/PASSWORD_KEYRING_NAME/cryptoKeys/PASSWORD_KEY_NAME
         envMap:
           PASSWORD: 'ENCRYPTED_PASSWORD'

JSON 

{
  "steps": [
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker login --username=$$USERNAME --password=$$PASSWORD"
    ],
    "secretEnv": [
      "USERNAME",
      "PASSWORD"
    ]
  },
  {
    "name": "gcr.io/cloud-builders/docker",
    "entrypoint": "bash",
    "args": [
      "-c",
      "docker pull $$USERNAME/REPOSITORY:TAG"
      ],
      "secretEnv": [
      "USERNAME"
    ]
  }
  ],
  "availableSecrets": {
    "inline": [{
      "kmsKeyName": "projects/PROJECT_ID/locations/global/keyRings/USERNAME_KEYRING_NAME/cryptoKeys/USERNAME_KEY_NAME",
      "envMap": {
        "USERNAME": "ENCRYPTED_USERNAME"
        }
    },
    {
    "kmsKeyName": "projects/PROJECT_ID/locations/global/keyRings/PASSWORD_KEYRING_NAME/cryptoKeys/PASSWORD_KEY_NAME",
    "envMap": {
        "PASSWORD": "ENCRYPTED_PASSWORD"
        }
    }]
  }
}

secrets

Secreto empareja un conjunto de variables de entorno secretas que contienen valores encriptados con la clave de Cloud KMS que se puede usar para desencriptar el valor.

serviceAccount

Usa este campo para especificar la cuenta de servicio de IAM que se usará en el momento de la compilación. Para obtener más información, consulta Configura cuentas de servicio especificadas por el usuario.

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

images

El campo images en el archivo de configuración de compilación especifica una o más imágenes de Docker de Linux que Cloud Build enviará a Artifact Registry. Es posible que tengas una compilación que realice tareas sin producir ninguna imagen de Docker de Linux, pero, si compilas imágenes y no las envías al registro, estas se descartan cuando se completa la compilación. Si no se produce una imagen especificada durante la compilación, esta fallará. Para obtener más información sobre el almacenamiento de imágenes, consulta Almacena artefactos en Artifact Registry.

Mediante la siguiente configuración de compilación, se establece el campo images a fin de almacenar la imagen de compilación:

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 especifica uno o más artefactos que se almacenarán en Cloud Storage o Artifact Registry después de que se completen correctamente todos los pasos de compilación.

objects

Dentro del campo artifacts, el campo object especifica uno o más artefactos que se almacenarán en Cloud Storage. Para obtener más información, consulta Almacena artefactos de compilación en Cloud Storage.

En la siguiente configuración de compilación, se establece el campo artifacts para almacenar el paquete de 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 de Go que no son contenedores a repositorios de Go en Artifact Registry. Para obtener más información, consulta Compila y prueba aplicaciones de Go.

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

Te recomendamos que uses una ruta de acceso 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 Compila y prueba aplicaciones de Go.

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

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 son contenedores a repositorios de Maven en Artifact Registry. Para obtener más información, consulta Compila y prueba aplicaciones de Java.

Ejemplo: Sube todos los archivos de Maven de una carpeta a un repositorio de Artifact Registry

La siguiente configuración de compilación establece el campo mavenArtifacts para subir todos los archivos de la carpeta /workspace/target/com/mycompany/app/my-app-1/1.0.0/ al repositorio de Artifact Registry https://us-central1-maven.pkg.dev/my-project-id/my-java-repo:

YAML 

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      deployFolder: '/workspace/target'
      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",
        "deployFolder": "/workspace/target",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

Para implementar tus archivos de Maven en /workspace/target/com/mycompany/app/my-app-1/1.0.0/, agrega la opción -DaltDeploymentRepository=local::default::file:./workspace/target a tu comando de implementación de Maven.

Ejemplo: Sube un archivo de Maven empaquetado a un repositorio de Artifact Registry

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

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 te permite subir paquetes de Python a Artifact Registry. Para obtener más información, consulta Compila y prueba aplicaciones de Python.

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

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 modo que suba tus paquetes de npm compilados a los repositorios compatibles en 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 de npm que se subirá. Este directorio debe contener un archivo package.json.

Te recomendamos que uses una ruta de acceso 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 Compila y prueba aplicaciones de Node.js.

La siguiente configuración de compilación establece el campo npmPackages para subir el paquete de npm en el 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"
      }
    ]
  }
}

oci

Usa el campo oci para configurar Cloud Build de modo que suba tus imágenes de OCI a los repositorios compatibles en Artifact Registry. Debes proporcionar valores para file y registryPath.

El campo registryPath especifica el repositorio de Artifact Registry en el que se almacenarán tus imágenes. El campo file especifica el directorio local que contiene la imagen de OCI que se subirá. Este directorio debe contener un archivo de imagen de OCI.

Te recomendamos que uses una ruta de acceso absoluta para el valor de file. Puedes usar . para hacer referencia al directorio de trabajo actual, pero el campo no se puede omitir ni dejar vacío.

La siguiente configuración de compilación establece el campo oci para subir la imagen de OCI en el directorio /.pack/layout-repo/my-app al repositorio de Artifact Registry https://us-east1-docker.pkg.dev/my-project/my-repo.

YAML 

artifacts:
  oci:
  - file: '/.pack/layout-repo/my-app'
    registryPath: 'https://us-east1-docker.pkg.dev/my-project/my-repo'
    tags: ["primary_image"]

JSON 

{
  "artifacts": {
    "oci": [
      {
        "file": "/.pack/layout-repo/my-app",
        "registryPath": "https://us-east1-docker.pkg.dev/my-project/my-repo",
        "tags": ["primary_image"]
      }
    ]
  }
}

genericArtifacts

Usa el campo genericArtifacts para subir archivos con tipos no especificados como un paquete nuevo dentro de un repositorio genérico en Artifact Registry. Esta configuración es útil si deseas subir archivos genéricos, como archivos de texto o objetos binarios, o si deseas subir un paquete que no sea un tipo de repositorio de Artifact Registry compatible.

En el campo folder, se especifica la carpeta que contiene los archivos que se subirán a tu repositorio genérico. El campo registryPath es la dirección del repositorio genérico de Artifact Registry que recibe los archivos de tu carpeta.

En la siguiente configuración de compilación, se establece el campo genericArtifacts para subir la carpeta /workspace/binaryOut al repositorio genérico de Artifact Registry projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version.

YAML 

artifacts:
  genericArtifacts:
  - folder: '/workspace/binaryOut'
    registryPath: 'projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version'

JSON 

{
  "artifacts": {
    "genericArtifacts": [
      {
        "folder": "/workspace/binaryOut",
        "registryPath": "projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version"
      }
    ]
  }
}

Puedes configurar un artefacto genérico como una dependencia de compilación para que Cloud Build descargue la dependencia antes de que comience la compilación. Para obtener más información, consulta Especifica un artefacto genérico como dependencia.

Usa Dockerfiles

Si ejecutas compilaciones de Docker en Cloud Build con la gcloud CLI o activadores de compilación, puedes usar un Dockerfile sin un archivo de configuración de compilación independiente. Si quieres realizar 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 compilar una imagen de Docker con un Dockerfile, consulta la Guía de inicio rápido: Compila.

Red de Cloud Build

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

YAML 

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

JSON 

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

Pasos siguientes