Esquema do ficheiro de configuração da compilação

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

Esta página explica o esquema do ficheiro de configuração do Cloud Build. Para obter instruções sobre como criar e usar um ficheiro de configuração de compilação, consulte o artigo Criar um ficheiro de configuração de compilação básico.

Estrutura de um ficheiro de configuração de compilação

Os ficheiros de configuração de compilação são modelados através do recurso Build da API Cloud Build.

Pode escrever o ficheiro de configuração de compilação com a sintaxe YAML ou JSON. Se enviar pedidos de compilação através de ferramentas HTTP de terceiros, como o curl, use a sintaxe JSON.

Um ficheiro de configuração de compilação tem a seguinte estrutura:

YAML 

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

JSON 

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

Cada uma das secções do ficheiro de configuração de compilação define uma parte da tarefa que quer que o Cloud Build execute:

Crie passos

Um passo de compilação especifica uma ação que quer que o Cloud Build execute. Para cada passo de compilação, o Cloud Build executa um contentor Docker como uma instância de docker run. Os passos de compilação são análogos aos comandos num script e oferecem-lhe a flexibilidade de executar instruções arbitrárias na sua compilação. Se conseguir criar um pacote de uma ferramenta de compilação num contentor, o Cloud Build pode executá-lo como parte da sua compilação. Por predefinição, o Cloud Build executa todos os passos de uma compilação em série na mesma máquina. Se tiver passos que podem ser executados em simultâneo, use a opção waitFor.

Pode incluir até 300 passos de compilação no ficheiro de configuração.

Use o campo steps no ficheiro de configuração de compilação para especificar um passo de compilação. Segue-se um fragmento do tipo de configuração que pode 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 um passo de compilação para especificar um cloud builder, que é uma imagem de contentor que executa ferramentas comuns. Usa um criador num passo de criação para executar as suas tarefas.

O fragmento seguinte mostra os passos de criação que chamam os criadores de 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 args de um passo de compilação recebe uma lista de argumentos e transmite-os ao criador de compilações referenciado pelo campo name. Os argumentos transmitidos ao criador são transmitidos à ferramenta que está a ser executada no criador, o que lhe permite invocar qualquer comando suportado pela ferramenta. Se o criador usado no passo de compilação tiver um ponto de entrada, os argumentos são usados como argumentos para esse ponto de entrada. Se o criador não definir um ponto de entrada, o primeiro elemento em args é usado como o ponto de entrada, e o restante é usado como argumentos.

Pode criar até 100 argumentos por passo. O comprimento máximo do argumento é de 10 000 carateres.

O seguinte fragmento 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 um passo de compilação recebe uma lista de variáveis de ambiente a usar quando o passo é executado. As variáveis têm o formato KEY=VALUE.

Na configuração de compilação seguinte, o campo env do passo de compilação define a zona do Compute Engine e o cluster do GKE antes de executar kubectl:

YAML 

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

JSON 

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

dir

Use o campo dir num passo de compilação para definir um diretório de trabalho a usar quando executar o contentor do passo. Se definir o campo dir no passo de compilação, o diretório de trabalho é definido como /workspace/<dir>. Se este valor for um caminho relativo, é relativo ao diretório de trabalho da compilação. Se este valor for absoluto, pode estar fora do diretório de trabalho da compilação. Nesse caso, o conteúdo do caminho pode não ser mantido nas execuções dos passos de compilação (a menos que seja especificado um volume para esse caminho).

O seguinte fragmento do código define o diretório de trabalho para o passo de compilação como /workspace/examples/hello_world:

YAML 

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

JSON 

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

timeout

Use o campo timeout num passo de compilação para definir um limite de tempo para a execução do passo. Se não definir este campo, o passo não tem limite de tempo e pode ser executado até ser concluído ou até o próprio processo de compilação atingir o limite de tempo. O campo timeout num passo de compilação não pode exceder o valor timeout especificado para uma compilação. timeout tem de ser especificado em segundos com até nove dígitos fracionários, terminado por "s". Exemplo: 3.5s

Na configuração de compilação seguinte, o passo ubuntu excede o tempo limite 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 num passo de compilação para especificar um script de shell a executar no passo. Se especificar script num passo de compilação, não pode especificar args nem entrypoint no mesmo passo. Para obter instruções sobre como usar o campo script, consulte o artigo Executar scripts bash.

automapSubstitutions

Se estiver definido como true, mapeie automaticamente todas as substituições e disponibilize-as como variáveis de ambiente num único passo. Se estiver definido como false, ignore as substituições para esse passo. Para ver exemplos, consulte o artigo Substitua valores de variáveis.

ID

Use o campo id para definir um identificador exclusivo para um passo de compilação. id é usado com o campo waitFor para configurar a ordem pela qual os passos de compilação devem ser executados. Para obter instruções sobre como usar waitFor e id, consulte o artigo Configurar a ordem dos passos de compilação.

waitFor

Use o campo waitFor num passo de compilação para especificar os passos que têm de ser executados antes de o passo de compilação ser executado. Se não forem fornecidos valores para waitFor, o passo de compilação aguarda que todos os passos de compilação anteriores no pedido de compilação sejam concluídos com êxito antes de ser executado. Para obter instruções sobre como usar waitFor e id, consulte o artigo Configurar a ordem dos passos de compilação.

entrypoint

Use o elemento entrypoint num passo de compilação para especificar um ponto de entrada se não quiser usar o ponto de entrada predefinido do criador. Se não definir este campo, o Cloud Build usa o ponto de entrada do criador. O fragmento seguinte define os pontos de entrada para o passo de compilaçã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 que são encriptadas através de uma chave criptográfica do Cloud KMS. Estes valores têm de ser especificados nos segredos da compilação. Para obter informações sobre a utilização deste campo, consulte o artigo Usar a variável encriptada em pedidos de compilação.

volumes

Um volume é um volume de contentor Docker que é montado em passos de compilação para persistir ficheiros em passos de compilação. Quando o Cloud Build executa um passo de compilação, monta automaticamente um volume workspace em /workspace. Pode especificar volumes adicionais a serem montados nos contentores dos passos de compilação através do campo volumes para os passos.

Por exemplo, o seguinte ficheiro de configuração de compilação escreve um ficheiro num volume no primeiro passo e lê-o no segundo passo. Se estes passos não especificassem o caminho /persistent_volume como um volume persistente, o primeiro passo escreveria o ficheiro nesse caminho e, em seguida, esse ficheiro seria rejeitado antes da execução do segundo passo. Ao especificar o volume com o mesmo nome em ambos os passos, o conteúdo de /persistent_volume no primeiro passo é mantido no segundo passo.

YAML 

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

JSON 

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

allowFailure

Num passo de compilação, se definir o valor do campo allowFailure como true e o passo de compilação falhar, a compilação é bem-sucedida, desde que todos os outros passos de compilação nessa compilação sejam bem-sucedidos.

Se todos os passos de compilação numa compilação tiverem o valor allowFailure definido como true e todos os passos de compilação falharem, o estado da compilação continua a ser Successful.

allowExitCodes tem precedência sobre este campo.

O seguinte fragmento do código permite que a compilação seja bem-sucedida quando o primeiro passo falha:

YAML 

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

JSON 

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

allowExitCodes

Use o campo allowExitCodes para especificar que uma falha de passo de compilação pode ser ignorada quando esse passo devolve um código de saída específico.

Se um passo de compilação falhar com um código de saída correspondente ao valor que forneceu em allowExitCodes, o Cloud Build permite que este passo de compilação falhe sem que toda a compilação falhe.

Se 100% dos passos de compilação falharem, mas todos os passos terminarem com um código que especificou no campo allowExitCodes, a compilação continua a ser bem-sucedida.

No entanto, se o passo de compilação falhar e produzir outro código de saída, um que não corresponda ao valor especificado em allowExitCodes, a compilação geral falha.

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

Este campo tem prioridade sobre allowFailure.

O seguinte fragmento do código permite que a compilação seja bem-sucedida quando o primeiro passo falha com um dos códigos de saída fornecidos:

YAML 

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

JSON 

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

timeout

Use o campo timeout para uma compilação para especificar o tempo que a compilação tem de poder ser executada, com uma granularidade de segundos. Se este tempo expirar, o trabalho na compilação vai parar e o estado da compilação vai ser TIMEOUT. Se timeout não estiver definido, é aplicado um timeout predefinido de 60 minutos à compilação. O valor máximo que pode ser aplicado a timeout é de 24 horas. timeout tem de ser especificado em segundos com até nove dígitos fracionários, terminado por "s". Exemplo: 3.5s

No fragmento seguinte, timeout está definido como 660 segundos para evitar que a compilação expire devido à 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 período durante o qual uma compilação pode estar em fila. Se uma compilação estiver na fila durante mais tempo do que o valor definido em queueTtl, a compilação expira e o estado da compilação é definido como EXPIRED. Se não for indicado nenhum valor, o Cloud Build usa o valor predefinido de 3600s (1 hora). A contagem queueTtl começa a partir de createTime. queueTtl tem de ser especificado em segundos com até nove dígitos fracionários, terminado por "s", por exemplo, 3.5s.

No fragmento seguinte, timeout está definido como 20s e queueTtl está definido como 10s. O queueTtl começa a contar às createTime, que é a hora em que a compilação é pedida, e o timeout começa a contar às startTime, que é a hora em que a compilação começa. Por conseguinte, queueTtl expira às createTime + 10s, a menos que a compilação comece até essa altura.

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 para uma compilação para especificar um contentor do Cloud Storage onde os registos têm de ser escritos. Se não definir este campo, o Cloud Build usa um contentor predefinido para armazenar os registos de compilação.

O fragmento seguinte define um contentor de registos para armazenar os registos de compilação:

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 para a sua compilação:

enableStructuredLogging: Ativa o mapeamento dos campos de registo de compilação especificados para campos LogEntry quando o registo de compilação é enviado para o registo. Por exemplo, se o registo de compilação contiver um message, a mensagem aparece em textPayload ou jsonPayload.message na entrada de registo resultante. Os campos de registo que não são mapeáveis aparecem na entrada de registo jsonPayload. Para mais informações, consulte o artigo Mapeie campos de registo de compilação para campos de entrada de registo.

env: Uma lista de definições de variáveis de ambiente globais que vão existir para todos os passos de compilação nesta compilação. Se uma variável estiver definida globalmente e num passo de compilação, a variável usa o valor do passo de compilação. Os elementos têm o formato KEY=VALUE para a variável de ambiente KEY que recebe o valor VALUE.

secretEnv: Uma lista de variáveis de ambiente globais, encriptadas através de uma chave criptográfica do Cloud Key Management Service, que vão estar disponíveis para todos os passos de compilação nesta compilação. Estes valores têm de ser especificados no Secret da compilação.

volumes: Uma lista de volumes a montar globalmente para TODOS os passos de compilação. Cada volume é criado como um volume vazio antes de iniciar o processo de compilação. Após a conclusão da compilação, os volumes e o respetivo conteúdo são rejeitados. Os nomes e os caminhos de volumes globais não podem estar em conflito com os volumes definidos num passo de compilação. A utilização de um volume global numa compilação com apenas um passo não é válida, uma vez que significa um pedido de compilação com uma configuração incorreta.

pubsubTopic: Opção para fornecer um nome do tópico Pub/Sub para receber notificações do estado de compilação. Se não fornecer um nome, o Cloud Build usa o nome do tópico predefinido de cloud-builds. O seguinte fragmento 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 hash para a proveniência da origem. O seguinte fragmento 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áquinas virtuais com alta utilização de CPU para executar as suas compilações: dois tipos de máquinas com 8 CPUs e dois tipos de máquinas com 32 CPUs. O Cloud Build também oferece dois tipos de máquinas virtuais adicionais com 1 CPU e 2 CPUs para executar as suas compilações. O tipo de máquina predefinido é e2-standard-2 com 2 CPUs. Pedir uma máquina virtual com CPU elevado pode aumentar o tempo de arranque da compilação. Adicione a opção machineType para pedir uma máquina virtual com uma CPU mais elevada:

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 mais informações sobre a utilização da opção machineType, consulte o artigo Acelerar as compilações.

diskSizeGb: Use a opção diskSizeGb para pedir um tamanho do disco personalizado para a sua compilação. O tamanho máximo que pode pedir é de 4000 GB.

O seguinte fragmento pede um tamanho do 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 esta opção para especificar se quer fazer stream dos registos de compilação para o Cloud Storage. Por predefinição, o Cloud Build recolhe registos de compilação quando a compilação é concluída. Esta opção especifica se quer transmitir registos de compilação em tempo real através do processo de compilação. O fragmento seguinte especifica que os registos de compilaçã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 esta opção para especificar se quer armazenar registos no Cloud Logging ou no Cloud Storage. Se não definir esta opção, o Cloud Build armazena os registos no Cloud Logging e no Cloud Storage. Pode definir a opção logging como GCS_ONLY para armazenar os registos apenas no Cloud Storage. O seguinte fragmento especifica que os registos 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: A opção defaultLogsBucketBehavior permite-lhe configurar o Cloud Build para criar um contentor de registos predefinido no seu próprio projeto na mesma região que a sua compilação. Para mais informações, consulte o artigo Armazene registos de compilação num contentor regionalizado pertencente ao utilizador.

A seguinte configuração de compilação define o campo defaultLogsBucketBehavior com 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 esta opção para ativar ou desativar explicitamente a expansão de parâmetros do bash nas substituições. Se a sua compilação for invocada por um acionador, o campo dynamicSubstitutions é sempre definido como verdadeiro e não tem de ser especificado no ficheiro de configuração da compilação. Se a compilação for invocada manualmente, tem de definir o campo dynamicSubstitutions como verdadeiro para que as expansões de parâmetros do bash sejam interpretadas quando executar a compilação.

automapSubstitutions: Mapeie automaticamente todas as substituições para variáveis de ambiente que vão estar disponíveis durante toda a compilação. Para ver exemplos, consulte o artigo Substitua valores de variáveis.

substitutionOption: Vai definir esta opção juntamente com o campo substitutions abaixo para especificar o comportamento quando existir um erro nas verificações de substituição.

pool: Defina o valor deste campo para o nome do recurso do conjunto privado para executar a compilação. Para obter instruções sobre como executar uma compilação num conjunto privado, consulte o artigo Executar compilações num conjunto privado.

requestedVerifyOption: Defina o valor de requestedVerifyOption como VERIFIED para ativar e validar a geração de atestações e metadados de proveniência para a sua compilação. Depois de definida, as suas compilações só são marcadas como SUCCESS se forem geradas atestações e proveniência.

substitutions

Use substituições no ficheiro de configuração de compilação para substituir variáveis específicas no momento da compilação. As substituições são úteis para variáveis cujo valor não é conhecido até ao momento da compilação ou para reutilizar um pedido de compilação existente com valores de variáveis diferentes. Por predefinição, a compilação devolve um erro se existir uma variável de substituição em falta ou uma substituição em falta. No entanto, pode usar a opção ALLOW_LOOSE para ignorar esta verificação.

O fragmento seguinte usa substituições para imprimir "hello world." A opção de substituição ALLOW_LOOSE está definida, o que significa que a compilação não devolve um erro se houver uma variável de substituição em falta ou uma substituição em falta.

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 obter instruções adicionais sobre a utilização de substitutions, consulte o artigo Substituir valores de variáveis.

tags

Use o campo tags para organizar as suas compilações em grupos e filtrar as compilações. A configuração seguinte define duas etiquetas com os nomes 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 este campo para usar um segredo do Secret Manager com o Cloud Build. Para mais informações, consulte o artigo Usar segredos.

secrets

Secret associa um conjunto de variáveis de ambiente secretas que contêm valores encriptados à chave do Cloud KMS a usar para desencriptar o valor.

serviceAccount

Use este campo para especificar a conta de serviço do IAM a usar no momento da compilação. Para mais informações, consulte o artigo Configurar contas de serviço especificadas pelo utilizador.

Não pode especificar a conta de serviço do Cloud Build antigo neste campo.

images

O campo images no ficheiro de configuração de compilação especifica uma ou mais imagens do Docker do Linux a serem enviadas pelo Cloud Build para o Artifact Registry. Pode ter uma compilação que execute tarefas sem produzir imagens do Linux Docker, mas se criar imagens e não as enviar para o registo, as imagens são rejeitadas quando a compilação é concluída. Se não for produzida uma imagem especificada durante a compilação, a compilação falha. Para mais informações sobre o armazenamento de imagens, consulte o artigo Armazene artefactos no Artifact Registry.

A configuração de compilação seguinte 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 no ficheiro de configuração de compilação especifica um ou mais artefactos não contentores a serem armazenados no Cloud Storage. Para mais informações sobre como armazenar artefactos não contentorizados, consulte o artigo Armazene artefactos de compilação no Cloud Storage.

A seguinte configuração de compilação define o campo artifacts para armazenar o pacote Go compilado 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-lhe carregar módulos Go não contentorizados para repositórios Go no Artifact Registry. Para mais informações, consulte o artigo Crie e teste aplicações Go.

O campo repository_location especifica o repositório do Artifact Registry para armazenar os seus pacotes. O campo module_path especifica o diretório local que contém o módulo Go a carregar. Este diretório tem de conter um ficheiro go.mod.

Recomendamos a utilização de um caminho absoluto para o valor de module_path. Pode usar . para fazer referência ao diretório de trabalho atual, mas o campo não pode ser omitido nem ficar vazio. Para mais instruções sobre a utilização do module_path, consulte o artigo Crie e teste aplicações Go.

A seguinte configuração de compilação define o campo goModules para carregar o 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-lhe carregar artefactos Java não contentores para repositórios Maven no Artifact Registry. Para mais informações, consulte o artigo Crie e teste aplicações Java.

A seguinte configuração de compilação define o campo mavenArtifacts para carregar o ficheiro compactado 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-lhe carregar pacotes Python para o Artifact Registry. Para mais informações, consulte o artigo Crie e teste aplicações Python.

A seguinte configuração de compilação define o campo pythonPackages para carregar o 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 carregar os seus pacotes npm criados para repositórios suportados no Artifact Registry. Tem de fornecer valores para repository e packagePath.

O campo repository especifica o repositório do Artifact Registry para armazenar os seus pacotes. O campo packagePath especifica o diretório local que contém o pacote npm a carregar. Este diretório tem de conter um ficheiro package.json.

Recomendamos a utilização de um caminho absoluto para o valor de packagePath. Pode usar . para fazer referência ao diretório de trabalho atual, mas o campo não pode ser omitido nem ficar vazio. Para mais instruções sobre a utilização do npmPackages, consulte o artigo Crie e teste aplicações Node.js.

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

YAML 

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

JSON 

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

Usar ficheiros Docker

Se estiver a executar compilações do Docker no Cloud Build através da CLI gcloud ou de acionadores de compilação, pode usar um Dockerfile sem um ficheiro de configuração de compilação separado. Se quiser fazer mais ajustes às suas compilações do Docker, pode fornecer um ficheiro de configuração de compilação, além do Dockerfile. Para instruções sobre como criar uma imagem do Docker com um Dockerfile, consulte o artigo Início rápido: criar.

Rede do Cloud Build

Quando o Cloud Build executa cada passo de compilação, anexa o contentor do passo a uma rede Docker local denominada cloudbuild. A cloudbuild rede aloja Credenciais padrão da aplicação (ADC) que os Google Cloud serviços podem usar para encontrar automaticamente as suas credenciais. Se estiver a executar contentores Docker aninhados e quiser expor o ADC a um contentor subjacente ou usar gcloud num passo docker, use a flag --network no passo 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",
        "."
      ]
   }
  ]
}

O que se segue?