Esquema do arquivo de configuração do build

Um arquivo de configuração de build contém instruções para o Cloud Build executar tarefas com base nas suas especificações. Por exemplo, o arquivo de configuração do build pode conter instruções para criar, empacotar e enviar imagens Docker.

Nesta página, explicamos o esquema do arquivo de configuração do Cloud Build. Para instruções sobre como criar e usar um arquivo de configuração de versão, consulte Como criar um arquivo de configuração de versão básico.

Estrutura de um arquivo de configuração da criação

Os arquivos de configuração da versão são modelados por meio do recurso Build da API Cloud Build.

É possível gravar o arquivo de configuração da criação usando a sintaxe YAML ou JSON. Se você enviar solicitações de criação usando ferramentas http de terceiros, como curl, use a sintaxe JSON.

A estrutura do arquivo de configuração da criação é a seguinte:

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",
        "..."
    ]
}

Cada uma das seções do arquivo de configuração da versão define uma parte da tarefa que você quer que o Cloud Build execute:

Etapas de versão

Uma etapa de versão especifica uma ação que o Cloud Build deve executar. Para cada etapa da criação, o Cloud Build executa um contêiner de Docker como uma instância de docker run. As etapas da criação são análogas aos comandos em um script e oferecem a flexibilidade de execução de instruções arbitrárias na versão. Se você puder inserir uma ferramenta de build em um contêiner, o Cloud Build poderá executá-la como parte da versão. Por padrão, o Cloud Build executa todas as etapas de um build em série na mesma máquina. Caso haja etapas que possam ser executadas simultaneamente, use a opção waitFor.

É possível incluir até 300 etapas de build no arquivo de configuração.

Use o campo steps, do arquivo de configuração da build para especificar uma etapa de build. Veja um snippet do tipo de configuração que é possível definir no 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

Use o campo name de uma etapa da criação para especificar um criador de nuvem, que é uma imagem de contêiner em que estão sendo executadas ferramentas comuns. Use um builder em uma etapa de build para executar suas tarefas.

O snippet a seguir mostra etapas da criação usadas para chamar os criadores bazel, gcloud e 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

O campo argsde uma etapa da criação recebe uma lista de argumentos e os transmite ao criador referido no campo name. Os argumentos transmitidos ao builder são transmitidos à ferramenta em execução no builder, o que permite invocar qualquer comando compatível com a ferramenta. Se o criador usado na etapa da criação tiver um entrypoint, args será usado como argumentos para esse entrypoint. Se o criador não definir um entrypoint, o primeiro elemento em args será usado como entrypoint e os demais serão usados como argumento.

É possível criar até 100 argumentos por etapa. O tamanho máximo do argumento é de 10.000 caracteres.

O snippet a seguir invoca o comando docker build e instala as dependências do 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

O campo env de uma etapa da criação recebe uma lista de variáveis de ambiente a serem usadas na execução da etapa. As variáveis estão no formato KEY=VALUE.

Na configuração da criação a seguir, o campo env, da etapa da criação define a zona do Compute Engine e o cluster do GKE antes de executar o 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

Em uma etapa de build, se você definir o valor do campo allowFailure como true e a etapa falhar, o build será bem-sucedido, desde que todas as outras etapas sejam bem-sucedidas.

Se todas as etapas de um build tiverem allowFailure definido como true e todas as etapas falharem, o status do build ainda será Successful.

allowExitCodes tem prioridade sobre este campo.

O snippet de código a seguir permite que o build seja bem-sucedido quando a primeira etapa falha:

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

Use o campo allowExitCodes para especificar que uma falha na etapa de build pode ser ignorada quando essa etapa retornar um código de saída específico.

Se uma etapa de build falhar com um código de saída correspondente ao valor fornecido em allowExitCodes, o Cloud Build vai permitir que essa etapa falhe sem que todo o build falhe.

Se 100% das etapas de build falharem, mas todas as etapas forem encerradas com um código especificado no campo allowExitCodes, o build ainda será bem-sucedido.

No entanto, se a etapa de build falhar e produzir outro código de saída que não corresponda ao valor especificado em allowExitCodes, o build geral vai falhar.

Os códigos de saída relevantes para o build dependem do software. Por exemplo, "1" é um código de saída comum no Linux. Também é possível definir seus próprios códigos de saída nos scripts. O campo allowExitCodes aceita números até o máximo de 255.

Esse campo tem precedência sobre allowFailure.

O snippet de código a seguir permite que o build seja bem-sucedido quando a primeira etapa falha com um dos códigos de saída fornecidos:

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

Use o campo dir em uma etapa de versão para definir um diretório de trabalho a ser usado ao executar o contêiner da etapa. Se você definir o campo dir na etapa de criação, o diretório de trabalho será definido como /workspace/<dir>. Se esse valor for um caminho relativo, ele é relativo ao diretório de trabalho da criação. Se esse valor for absoluto, talvez ele esteja fora do diretório de trabalho da criação. Nesse caso, o conteúdo do caminho pode não ser permanente durante as execuções de etapas de criação, a não ser que seja especificado um volume para esse caminho.

O snippet de código a seguir define o diretório de trabalho para a etapa de build 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

Use o campo id para definir um identificador exclusivo para uma etapa de build. id é usado com o campo waitFor para configurar a ordem em que as etapas de criação devem ser executadas. Para receber instruções sobre como usar waitFor e id, consulte Como configurar a ordem das etapas de criação.

waitFor

Use o campo waitFor em uma etapa de criação para especificar as etapas que precisam ser executadas antes que a etapa de criação seja executada. Se nenhum valor for informado para waitFor, a etapa de criação aguardará até que todas as etapas de criação anteriores, que façam parte da solicitação da criação, sejam concluídas com êxito, antes de proceder à execução. Para receber instruções sobre como usar waitFor e id, consulte Como configurar a ordem das etapas de criação.

entrypoint

Se você não quiser usar o entrypoint padrão do criador em uma etapa de criação, use entrypoint para especificar um. Se você não definir esse campo, o Cloud Build usará o entrypoint do criador. O snippet a seguir define os entrypoints da etapa de criação 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

Uma lista de variáveis de ambiente criptografadas com uma chave de criptografia do Cloud KMS. Esses valores precisam ser especificados nos segredos da criação. Para informações sobre como usar esse campo, consulte Como usar a variável criptografada em solicitações de criação.

volumes

Um Volume é um volume de contêiner do Docker montado em etapas de build para manter arquivos entre as etapas de build. Quando o Cloud Build executa uma etapa de criação, ele monta automaticamente um volume workspace em /workspace. Especifique mais volumes a serem montados nos contêineres das etapas de criação usando o campo volumes para suas etapas

Por exemplo, o arquivo de configuração da criação a seguir grava um arquivo em um volume na primeira etapa e faz a respectiva leitura na segunda etapa. Se o caminho /persistent_volume não for especificado por essas etapas como um volume permanente, a primeira etapa gravará o arquivo nesse caminho e depois esse arquivo será descartado antes da execução da segunda etapa Ao especificar o volume com o mesmo nome nas duas etapas, o conteúdo de /persistent_volume na primeira etapa é mantido na segunda etapa.

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

Para definir um limite de tempo para execução da etapa de criação, use o campo timeout em uma etapa. Se você não definir esse campo, a etapa será executada até ser concluída ou até que o próprio build expire. O campo timeout de uma etapa de build não pode exceder o valor timeout especificado para o build.

timeout é especificado em segundos (usando o formato Duration) com até nove dígitos fracionários, terminando em s (por exemplo: 3.5s).

Na seguinte configuração de build, a etapa ubuntu expira após 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

Use o campo script em uma etapa de build para especificar um script de shell a ser executado na etapa. Se você especificar script em uma etapa de build, não será possível especificar args ou entrypoint na mesma etapa. Para instruções sobre como usar o campo script, consulte Como executar scripts bash.

automapSubstitutions

Se definido como true, mapeie automaticamente todas as substituições e disponibilize-as como variáveis de ambiente em uma única etapa. Se definido como false, ignore as substituições dessa etapa. Para ver exemplos, consulte Substituir valores de variáveis.

resultados

Permite que uma etapa de build armazene dados e os anexe a um atestado nos resultados do build após a conclusão. Os dados armazenados precisam ser um par de chave-valor, em que a chave é uma string e o valor é um objeto JSON. Um resultado precisa ter os seguintes campos:

  • name: o nome do resultado. Esse nome aparece no atestado resultante nos resultados do build. Também é possível usar esse nome para referenciar o resultado em uma etapa de build. Por exemplo, é possível anexar valores ao resultado usando um script na mesma etapa de build.
  • attestationContent: (opcional) o nome do atestado. Pode ser qualquer valor e vai aparecer no atestado resultante nos resultados do build. Esse campo só é necessário se você planeja validar os atestados de build.
  • attestationType: (opcional) o tipo de atestado. Pode ser qualquer valor e vai aparecer no atestado resultante nos resultados do build. Esse campo só é necessário se você planeja validar os atestados de build.

A versão a seguir usa uma configuração de resultado para gerar um atestado que permite aos usuários verificar se a versão usou apenas URLs com prefixos compatíveis para criar a imagem. Neste exemplo, um resultado é definido como allowlisted_prefixes. Em seguida, allowlisted_prefixes é definido como o par de chave-valor de allowlisted_prefixes e [\"github.com\", \"gitlab.com\"] e, em seguida, anexado como um atestado aos resultados do build.

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

Use o campo timeout fora de uma etapa de build para definir o limite de tempo geral para executar o build. Se esse tempo acabar, o trabalho no build será interrompido e o status do build será TIMEOUT.

Se timeout não for definido, o build usará um timeout padrão de 60 minutos. O valor máximo de timeout é 24 horas. timeout é especificado em segundos, usando o formato Duração, com até nove dígitos fracionários, terminando com s (por exemplo: 3.5s).

No snippet a seguir, timeout está definido como 660 segundos, para evitar que a criação exceda o tempo limite devido ao modo de suspensão:

YAML

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

JSON 

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

queueTtl

Use o campo queueTtl para especificar o tempo que uma versão pode ficar na fila. Se uma versão estiver na fila por mais tempo do que o valor definido em queueTtl, ela expirará e o status da versão será definido como EXPIRED. Se nenhum valor for fornecido, o Cloud Build usará o valor padrão de 3600s (1 hora). queueTtl começa a contar a partir de createTime. queueTtl precisa ser especificado em segundos com até nove dígitos fracionários, terminados por "s", por exemplo, 3.5s.

No snippet a seguir, timeout está definido como 20s e queueTtl está definido como 10s. queueTtl começa a contar em createTime, que é o momento em que o build é solicitado, e timeout começa a contar em startTime, que é o momento em que o build começa. Portanto, queueTtl vai expirar em createTime + 10s, a menos que o build comece até lá.

YAML 

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

JSON 

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

logsBucket

Defina o campo logsBucket de um build para especificar um bucket do Cloud Storage em que os registros de build precisam ser gravados. Se você não definir esse campo, o Cloud Build vai usar o valor de defaultLogsBucketBehavior para armazenar os registros de build em um bucket criado pelo Cloud Build no Cloud Storage.

O snippet a seguir define o Cloud Build para armazenar registros de build em um bucket personalizado no 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

Use o campo options para especificar os seguintes argumentos opcionais do seu build:

enableStructuredLogging: ativa o mapeamento de campos de registro de build especificados para campos LogEntry quando o registro de build é enviado ao Logging. Por exemplo, se o registro de build tiver um message, a mensagem vai aparecer em textPayload ou jsonPayload.message na entrada de registro resultante. Os campos de registro de build que não podem ser mapeados aparecem na entrada de registro jsonPayload. Para mais informações, consulte Mapear campos de registro de build para campos de entrada de registro.

env : uma lista de definições de variáveis de ambiente global para todas as etapas de criação nessa criação. Se uma variável for definida tanto globalmente quanto em uma etapa de criação, a variável usará o valor da etapa de criação. Os elementos estão no formato KEY=VALUE para a variável de ambiente KEY receber o valor VALUE.

secretEnv: uma lista de variáveis de ambiente globais, criptografadas usando uma chave de criptografia do Cloud Key Management Service, que estarão disponíveis para todas as etapas de build neste build. É preciso que esses valores sejam especificados no Secret da criação.

volumes : uma lista de volumes a serem montados globalmente para TODAS as etapas de criação. Cada volume é criado como um volume vazio, antes do início do processo de criação. Após a conclusão da versão, os volumes e seus conteúdos são descartados. Os caminhos e nomes de volume globais não podem entrar em conflito com os volumes definidos em uma etapa de criação. O uso de um volume global em uma criação com apenas uma etapa não é válido porque isso significa uma solicitação de criação com uma configuração incorreta.

pubsubTopic: opção para fornecer um nome de tópico do Pub/Sub para receber notificações de status do build. Se você não fornecer um nome, o Cloud Build usará o nome de tópico padrão de cloud-builds. O snippet a seguir especifica que o nome do tópico do Pub/Sub é 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 : defina a opção sourceProvenanceHash para especificar o algoritmo de hash para a origem. O snippet a seguir especifica que o algoritmo hash é 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: o Cloud Build oferece quatro tipos de máquina virtual com grande quantidade de CPUs para executar seus builds: dois tipos de máquina com 8 CPUs e dois tipos de máquina com 32 CPUs. O Cloud Build também oferece dois tipos adicionais de máquina virtual com 1 CPU e 2 CPUs para executar os builds. O tipo de máquina padrão é e2-standard-2 com 2 CPUs. Solicitar uma máquina virtual com mais CPUs do que o padrão pode aumentar o tempo de inicialização do build. Adicione a opção machineType para solicitar uma máquina virtual com mais CPUs do que o padrão:

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 receber mais informações sobre como usar a opção machineType, consulte Como acelerar as criações .

diskSizeGb : use a opção diskSizeGb para solicitar um tamanho de disco personalizado para sua criação. O tamanho máximo que você pode solicitar é de 4.000 GB.

O snippet a seguir solicita um tamanho 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: use essa opção para especificar que seja feito stream de registros de criação para o Cloud Storage. Por padrão, o Cloud Build coleta registros de criação na conclusão da criação. Essa opção especifica se você quer transmitir registros de criação em tempo real por meio do processo de criação. O snippet a seguir especifica que os registros de versão são transmitidos para o 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: use essa opção para especificar se você quer armazenar registros de build no Cloud Logging ou no Cloud Storage:

  • GCS_ONLY: os registros de build são enviados para buckets do Cloud Storage.
  • CLOUD_LOGGING_ONLY: os registros de build são enviados para buckets do Logging.
  • LEGACY: os registros de build são enviados para buckets nos dois locais. Se logging não estiver definido, o Cloud Build usará esse valor.
  • NONE: os registros de build não são armazenados.

Para mais informações sobre os benefícios e as considerações sobre o armazenamento de registros de build, consulte Opções de armazenamento de registros de build.

O snippet a seguir especifica que os registros de build são armazenados no 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:

Use esse campo quando logging estiver configurado para enviar os registros de build ao Cloud Storage.

Quando logging tem um valor de GCS_ONLY, Legacy ou é indefinido, os registros de build são enviados para buckets no Cloud Storage. Nesse caso, o Cloud Build avalia os campos logsBucket e defaultLogsBucketBehavior para determinar qual bucket do Cloud Storage recebe os registros de build:

logsBucket defaultLogsBucketBehavior Onde os registros de build são armazenados
Bucket especificado Valor ignorado No bucket especificado em logsBucket
Nenhum valor REGIONAL_USER_OWNED_BUCKET Em um bucket criado pelo Cloud Build e de propriedade do usuário
Nenhum valor LEGACY_BUCKET Em um bucket criado pelo Cloud Build e de propriedade do Google Cloud
Nenhum valor Nenhum valor Em um bucket criado pelo Cloud Build e de propriedade do usuário. Se a criação desse bucket falhar, os registros de build serão armazenados em um bucket criado pelo Cloud Build e de propriedade do Google Cloud.

Para mais informações, consulte Opções de armazenamento de registros de build.

A configuração de build a seguir define o campo defaultLogsBucketBehavior como o 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: use essa opção para ativar ou desativar explicitamente a expansão de parâmetro bash nas substituições. Se o build for invocado por um gatilho, o campo dynamicSubstitutions será sempre definido como "true" e não precisará ser especificado no arquivo de configuração da compilação. Caso sua versão seja invocada manualmente, você precisa definir o campo dynamicSubstitutions como verdadeiro para que as expansões de parâmetro bash sejam interpretadas ao executar sua versão.

automapSubstitutions: mapeia automaticamente todas as substituições para variáveis de ambiente que estarão disponíveis em todo o build. Para ver exemplos, consulte Substituir valores de variáveis.

substitutionOption : você definirá essa opção com o campo substitutions abaixo para especificar o comportamento quando houver um erro nas verificações de substituição.

pool: defina o valor desse campo como o nome do recurso do pool particular para executar o build. Para instruções sobre como executar um build em um pool particular, consulte Como executar builds em um pool particular.

requestedVerifyOption: defina o valor de requestedVerifyOption como VERIFIED para ativar e verificar a geração de atestados e metadados de procedência para seu build. Depois de definido, os builds só serão marcados como SUCCESS se os atestados e a procedência forem gerados.

workerRelease: escolha um canal de lançamento ou uma versão específica.

A configuração de build a seguir define o campo workerRelease como o canal normal:

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"
    }
}

O exemplo a seguir define o campo workerRelease como uma versão 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

Use substituições em seu arquivo de configuração da criação para substituir variáveis específicas no momento da criação. As substituições são úteis para variáveis que tenham um valor não conhecido até o momento da criação ou para reutilizar uma solicitação de versão existente com diferentes valores variáveis. Por padrão, a criação retornará um erro se faltar uma variável de substituição ou uma substituição. No entanto, é possível usar a opção ALLOW_LOOSE para ignorar essa verificação.

O snippet a seguir usa substituições para imprimir "hello world". A opção de substituição ALLOW_LOOSE está definida, isto é, a criação não retornará um erro se faltar uma variável de substituição ou uma substituição.

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 receber mais instruções sobre o uso de substitutions, consulte Como substituir valores de variável.

tags

Use o campo tags para organizar suas criações em grupos e filtrar suas criações. A configuração a seguir define duas tags chamadas mytag1 e 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

Use esse campo para referenciar um ou mais secrets do Secret Manager ou do Cloud KMS na solicitação de build. O Cloud Build pode usar esses secrets para realizar uma ação durante o processo de build, como fazer login em uma conta.

Secret Manager

Para usar secrets do Secret Manager no arquivo de configuração do build, adicione um campo secretManager ao campo availableSecrets no arquivo de configuração do build. O campo secretManager contém um ou mais pares dos campos versionName e env:

  • versionName: o caminho para o secret no Secret Manager.
  • env: um nome local (variável de ambiente) que as etapas de build podem usar para fazer referência ao secret.

O campo secretEnv em uma etapa de build especifica quais variáveis de ambiente podem ser usadas nessa etapa.

A configuração a seguir mostra como fazer login no Docker usando um nome de usuário e uma senha do Docker armazenados no 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 mais informações, consulte Como usar secrets.

Cloud KMS

Para usar as chaves do Cloud KMS no arquivo de configuração do build, adicione um campo inline ao campo availableSecrets no arquivo de configuração do build. O campo inline contém um ou mais pares de kmsKeyName e envMap:

  • kmsKeyName: o caminho para a chave do Cloud KMS.
  • envMap: um nome local (mapeamento de ambiente) que as etapas de build podem usar para fazer referência ao secret.

O campo secretEnv em uma etapa de build especifica quais variáveis de ambiente podem ser usadas nessa etapa.

A configuração a seguir mostra como fazer login no Docker usando um nome de usuário e uma senha do Docker armazenados no 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

Um secret combina um conjunto de variáveis de ambiente secretas contendo valores criptografados com a chave do Cloud KMS a ser usada para descriptografar o valor.

serviceAccount

Use este campo para especificar a conta de serviço do IAM a ser usada no momento da criação. Para mais informações, consulte Como configurar contas de serviço especificadas pelo usuário.

Não é possível especificar a conta de serviço legada do Cloud Build nesse campo.

images

O campo images no arquivo de configuração do build especifica uma ou mais imagens do Docker do Linux a serem enviadas pelo Cloud Build para o Artifact Registry. É possível ter um build que execute tarefas sem produzir imagens Docker do Linux, mas se você criar imagens e não as enviar para o registro, elas serão descartadas após a conclusão do build. Se uma imagem especificada não for produzida durante a versão, a versão apresentará falha. Para mais informações sobre como armazenar imagens, consulte Armazenar artefatos no Artifact Registry.

A seguinte configuração da criação define o campo images para armazenar a imagem criada:

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

O campo artifacts especifica um ou mais artefatos a serem armazenados no Cloud Storage ou no Artifact Registry após a conclusão de todas as etapas do build.

objects

No campo artifacts, o campo object especifica um ou mais artefatos a serem armazenados no Cloud Storage. Para mais informações, consulte Armazenar artefatos de build no Cloud Storage.

A configuração de build a seguir define o campo artifacts para armazenar o pacote Go criado em 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

O campo goModules permite fazer upload de módulos do Go que não são de contêiner para repositórios do Go no Artifact Registry. Para mais informações, consulte Criar e testar aplicativos Go.

O campo repository_location especifica o repositório do Artifact Registry para armazenar seus pacotes. O campo module_path especifica o diretório local que contém o módulo Go para upload. Esse diretório precisa conter um arquivo go.mod.

Recomendamos usar um caminho absoluto para o valor de module_path. É possível usar . para se referir ao diretório de trabalho atual, mas o campo não pode ser omitido nem deixado em branco. Para mais instruções sobre como usar module_path, consulte Criar e testar aplicativos Go.

A configuração de build a seguir define o campo goModules para fazer upload do módulo em example.com/myapp para o repositório do 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

O campo mavenArtifacts permite fazer upload de artefatos Java que não são de contêiner para repositórios do Maven no Artifact Registry. Para mais informações, consulte Criar e testar aplicativos Java.

Exemplo: fazer upload de todos os arquivos do Maven em uma pasta para um repositório do Artifact Registry

A configuração de build a seguir define o campo mavenArtifacts para fazer upload de todos os arquivos na pasta /workspace/target/com/mycompany/app/my-app-1/1.0.0/ para o repositório do 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 implantar os arquivos do Maven no /workspace/target/com/mycompany/app/my-app-1/1.0.0/, adicione a opção -DaltDeploymentRepository=local::default::file:./workspace/target ao comando de implantação do Maven.

Exemplo: fazer upload de um arquivo Maven empacotado para um repositório do Artifact Registry

A configuração de build a seguir define o campo mavenArtifacts para fazer upload do arquivo empacotado my-app-1.0-SNAPSHOT.jar para o repositório do 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

O campo pythonPackages permite fazer upload de pacotes Python para o Artifact Registry. Para mais informações, consulte Criar e testar aplicativos Python.

A configuração de build a seguir define o campo pythonPackages para fazer upload do pacote Python dist/my-pkg.whl para o repositório do 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

Use o campo npmPackages para configurar o Cloud Build para fazer upload dos pacotes npm criados para repositórios compatíveis no Artifact Registry. É preciso fornecer valores para repository e packagePath.

O campo repository especifica o repositório do Artifact Registry para armazenar seus pacotes. O campo packagePath especifica o diretório local que contém o pacote npm para upload. Esse diretório precisa conter um arquivo package.json.

Recomendamos usar um caminho absoluto para o valor de packagePath. É possível usar . para se referir ao diretório de trabalho atual, mas o campo não pode ser omitido nem deixado em branco. Para mais instruções sobre como usar npmPackages, consulte Criar e testar aplicativos Node.js.

A configuração de build a seguir define o campo npmPackages para fazer upload do pacote npm no diretório /workspace/my-pkg para o repositório https://us-east1-npm.pkg.dev/my-project/my-repo do Artifact Registry.

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

Use o campo oci para configurar o Cloud Build para fazer upload das suas imagens OCI para repositórios compatíveis no Artifact Registry. É preciso fornecer valores para file e registryPath.

O campo registryPath especifica o repositório do Artifact Registry para armazenar suas imagens. O campo file especifica o diretório local que contém a imagem OCI para upload. Esse diretório precisa conter um arquivo de imagem OCI.

Recomendamos usar um caminho absoluto para o valor de file. É possível usar . para se referir ao diretório de trabalho atual, mas o campo não pode ser omitido nem deixado em branco.

A configuração de build a seguir define o campo oci para fazer upload da imagem OCI no diretório /.pack/layout-repo/my-app para o repositório do 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

Use o campo genericArtifacts para fazer upload de arquivos com tipos não especificados como um novo pacote em um repositório genérico no Artifact Registry. Essa configuração é útil se você quiser fazer upload de arquivos genéricos, como arquivos de texto ou binários, ou se quiser fazer upload de um pacote que não seja um tipo de repositório compatível com o Artifact Registry.

O campo folder especifica a pasta que contém os arquivos a serem enviados para o repositório genérico. O campo registryPath é o endereço do repositório genérico do Artifact Registry que recebe os arquivos da sua pasta.

A configuração de build a seguir define o campo genericArtifacts para fazer upload da pasta /workspace/binaryOut para o repositório genérico projects/my-project/locations/us-east1/repositories/my-repo/packages/my-pkg/versions/my-version do Artifact Registry.

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"
      }
    ]
  }
}

É possível configurar um artefato genérico como uma dependência de build para que o Cloud Build faça o download da dependência antes do início do build. Para mais informações, consulte Especificar um artefato genérico como uma dependência.

Como usar Dockerfiles

Se você estiver executando builds do Docker no Cloud Build usando a CLI gcloud ou gatilhos de build, use um Dockerfile sem um arquivo de configuração de build separado. Se você quiser fazer mais ajustes nos builds do Docker, forneça um arquivo de configuração de build além do Dockerfile. Para instruções sobre como criar uma imagem Docker usando um Dockerfile, consulte Guia de início rápido: criar.

Rede do Cloud Build

Quando o Cloud Build executa cada etapa de build, ele anexa o contêiner da etapa a uma rede local do Docker denominada cloudbuild. A rede cloudbuild hospeda o Application Default Credentials (ADC) que os serviços do Google Cloud podem usar para encontrar suas credenciais automaticamente. Se você estiver executando contêineres do Docker aninhados e quiser expor o ADC a um contêiner subjacente ou usar gcloud em uma etapa docker, use a flag --network na etapa build do 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",
        "."
      ]
   }
  ]
}

A seguir