Schema del file di configurazione di compilazione

Un file di configurazione della build contiene istruzioni per consentire a Cloud Build di eseguire le attività in base alle tue specifiche. Ad esempio, il file di configurazione della build può contenere istruzioni per la creazione, la pacchettizzazione e il push delle immagini Docker.

Questa pagina illustra lo schema del file di configurazione di Cloud Build. Per istruzioni sulla creazione e l'utilizzo di un file di configurazione della build, consulta la sezione Creare un file di configurazione della build di base.

Struttura di un file di configurazione della build

I file di configurazione della build sono modellati utilizzando la risorsa dell'API Cloud Build Build.

Puoi scrivere il file di configurazione della build utilizzando la sintassi YAML o JSON. Se invii richieste di build utilizzando strumenti http di terze parti come curl, usa la sintassi JSON.

Un file di configurazione della build ha la seguente struttura:

YAML

steps:
- name: string
  args: [string, string, ...]
  env: [string, string, ...]
  dir: string
  id: string
  waitFor: [string, string, ...]
  entrypoint: string
  secretEnv: string
  volumes: object(Volume)
  timeout: string (Duration format)
  script: string
- 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
 logStreamingOption: enum(LogStreamingOption)
 logging: enum(LoggingMode)
 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)
images:
- [string, string, ...]

JSON

{
    "steps": [
    {
        "name": "string",
        "args": [
            "string",
            "string",
            "..."
        ],
        "env": [
            "string",
            "string",
            "..."
        ],
        "dir": "string",
        "id": "string",
        "waitFor": [
            "string",
            "string",
            "..."
        ],
        "entrypoint": "string",
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "timeout": "string (Duration format)",
        "script" : "string"
    },
    {
        "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",
        "logStreamingOption": "enum(LogStreamingOption)",
        "logging": "enum(LoggingMode)"
        "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)",
    "images": [
        "string",
        "string",
        "..."
    ]
}

Ogni sezione del file di configurazione della build definisce una parte dell'attività che desideri venga eseguita da Cloud Build:

Passi build

Un passaggio build specifica un'azione che deve essere eseguita da Cloud Build. Per ogni passaggio della build, Cloud Build esegue un container docker come istanza di docker run. I passaggi della build sono analoghi ai comandi di uno script e ti offrono la flessibilità di eseguire istruzioni arbitrarie nella build. Se puoi pacchettizzare uno strumento di build in un container, Cloud Build può eseguirlo come parte della tua build. Per impostazione predefinita, Cloud Build esegue tutti i passaggi di una build in serie sulla stessa macchina. Se hai passaggi che possono essere eseguiti contemporaneamente, utilizza l'opzione waitFor.

Puoi includere fino a 100 passi di build nel file di configurazione.

Utilizza il campo steps nel file di configurazione della build per specificare un passaggio di build. Ecco uno snippet del tipo di configurazione che potresti impostare nel 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

Utilizza il campo name di un passaggio di build per specificare un generatore di cloud, ovvero un'immagine container che esegue strumenti comuni. Devi utilizzare un builder in un passaggio di build per eseguire le tue attività.

Il seguente snippet mostra i passaggi di build che chiamano i builder 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

Il campo args di un passaggio di build prende un elenco di argomenti e li passa al generatore al quale fa riferimento il campo name. Gli argomenti passati al builder vengono passati allo strumento in esecuzione nel builder, che puoi richiamare qualsiasi comando supportato dallo strumento. Se il builder utilizzato nel passaggio di build ha un punto di ingresso, gli argomenti verranno utilizzati come argomenti per quel punto di ingresso. Se il builder non definisce un punto di ingresso, il primo elemento in args verrà utilizzato come entrypoint e il resto verrà utilizzato come argomenti.

Puoi creare fino a 100 argomenti per passaggio. La lunghezza massima degli argomenti è 4000.

Il seguente snippet richiama il comando docker build e installa le dipendenze 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

Il campo env di un passaggio di build prende un elenco di variabili di ambiente da utilizzare durante l'esecuzione del passaggio. Le variabili sono nel formato KEY=VALUE.

Nella seguente configurazione di compilazione, il campo env del passaggio di build imposta la zona di Compute Engine e il cluster GKE prima di eseguire il comando 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

Utilizza il campo dir in un passaggio di compilazione per impostare una directory di lavoro da utilizzare durante l'esecuzione del container del passaggio. Se imposti il campo dir nel passaggio della build, la directory di lavoro è impostata su /workspace/<dir>. Se questo valore è un percorso relativo, è relativo alla directory di lavoro di build. Se questo valore è assoluto, potrebbe non trovarsi nella directory di lavoro della build e in questo caso i contenuti del percorso potrebbero non essere salvati in modo permanente nelle esecuzioni dei passaggi di build (a meno che non venga specificato un volume per quel percorso).

Il seguente snippet di codice imposta la directory di lavoro per il passaggio di build su /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

Utilizza il campo timeout in un passaggio di compilazione per impostare un limite di tempo per l'esecuzione del passaggio. Se non imposti questo campo, il passaggio non avrà limiti di tempo e potrà essere eseguito fino al completamento o al timeout della build. Il campo timeout in un passaggio di build non deve superare il valore timeout specificato per una build. timeout deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminate con 's'. Esempio: "3,5s"

Nella configurazione di build seguente, il passaggio ubuntu scade dopo 500 secondi:

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

Utilizza il campo script in un passaggio di compilazione per specificare uno script shell da eseguire nel passaggio. Se specifichi script in un passaggio di build, non puoi specificare args o entrypoint nello stesso passaggio. Per istruzioni sull'utilizzo del campo script, consulta la sezione Esecuzione di script bash.

id

Utilizza il campo id per impostare un identificatore univoco per un passaggio di build. id viene utilizzato con il campo waitFor per configurare l'ordine in cui devono essere eseguiti i passi della build. Per istruzioni sull'utilizzo di waitFor e id, consulta la sezione Configurazione dell'ordine dei passaggi di build.

waitFor

Utilizza il campo waitFor in un passaggio di creazione per specificare quali passaggi devono essere eseguiti prima di eseguire il passaggio. Se non specifichi valori per waitFor, il passaggio della build attende che tutti i passaggi precedenti della build siano completati correttamente prima dell'esecuzione. Per istruzioni sull'utilizzo di waitFor e id, consulta la sezione Configurazione dell'ordine dei passaggi di build.

entrypoint

Usa il campo entrypoint in un passaggio di build per specificare un punto di ingresso se non vuoi usare il punto di contatto predefinito del builder. Se non imposti questo campo, Cloud Build utilizzerà il punto di contatto del builder. Il seguente snippet imposta i punti di ingresso per il passaggio di build 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

Un elenco di variabili di ambiente criptate con una chiave di crittografia Cloud KMS. Questi valori devono essere specificati nei secret della build. Per informazioni sull'utilizzo di questo campo, consulta Utilizzo della variabile criptata nelle richieste di build.

volumes

Un volume è un volume di container Docker montato in passaggi di build per rendere i file persistenti tra i passaggi di build. Quando Cloud Build esegue un passaggio di build, monta automaticamente un volume workspace in /workspace. Puoi specificare volumi aggiuntivi da montare nei passi della build' container utilizzando il campo volumes per i passi.

Ad esempio, il seguente file di configurazione della build scrive un file in un volume nel primo passaggio e lo legge nel secondo. Se questi passaggi non specificavano il percorso /persistent_volume come volume permanente, il primo passaggio scriverebbe il file in quel percorso, quindi il file verrebbe eliminato prima dell'esecuzione del secondo passaggio. Specificando il volume con lo stesso nome in entrambi i passaggi, i contenuti di /persistent_volume nel primo passaggio vengono mantenuti al secondo.

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

Utilizza il campo timeout per una build per specificare il tempo necessario per eseguire la build, in base alla seconda granularità. Se scade, il lavoro sulla build verrà interrotto e lo stato della build sarà TIMEOUT. Se timeout non è impostato, alla build verrà applicato un valore predefinito di timeout di 10 minuti. Il valore massimo che può essere applicato a timeout è 24 ore. timeout deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminate con 's'. Esempio: "3,5s"

Nel seguente snippet, timeout è impostato su 660 secondi per evitare che la build scada del tempo a causa del sonno:

YAML

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

JSON

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

queueTtl

Utilizza il campo queueTtl per specificare il periodo di tempo per cui una build può essere messa in coda. Se una build è in coda per un tempo superiore al valore impostato in queueTtl, la build scade e lo stato della build è impostato su EXPIRED. Se non specifichi alcun valore, Cloud Build utilizza il valore predefinito "3600s" (1 ora). queueTtl inizia a spuntare da createTime. queueTtl deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminate da 's', ad esempio, "quot;3,5s".

Nel seguente snippet timeout è impostato su "20s" e queueTtl è impostato su "10s". queueTtl inizia il ticchettio di createTime, che è il momento in cui viene richiesta, e timeout inizia il tick a startTime, che è il momento in cui inizia la build. Pertanto, queueTtl scadrà a createTime + 10 s a meno che la build non inizi entro quella data.

YAML

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

JSON

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

logsBucket

Imposta il campo logsBucket per una build in modo da specificare un bucket Cloud Storage in cui devono essere scritti i log. Se non imposti questo campo, Cloud Build utilizzerà un bucket predefinito per archiviare i log della build.

Lo snippet seguente imposta un bucket di log per archiviare i log di build:

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

Utilizza il campo options per specificare i seguenti argomenti facoltativi per la build:

env: un elenco di definizioni di variabili di ambiente globali esistenti per tutti i passaggi di build in questa build. Se una variabile è definita sia a livello globale sia in un passaggio di build, la variabile utilizzerà il valore del passaggio di build. Gli elementi sono nel formato KEY=VALUE per la variabile di ambiente KEY a cui è stato assegnato il valore VALUE.

secretEnv: un elenco di variabili di ambiente globali, criptate mediante una chiave di crittografia Cloud Key Management Service, disponibile per tutti i passaggi della build. Questi valori devono essere specificati nella Secret della build.

volumes: Un elenco dei volumi da montare a livello globale per TUTTI i passaggi della build. Ogni volume viene creato come volume vuoto prima di iniziare il processo di compilazione. Al termine della build, i volumi e i relativi contenuti vengono eliminati. I nomi e i percorsi dei volumi globali non possono essere in conflitto con i volumi definiti in un passaggio di build. L'utilizzo di un volume globale in una build con un solo passaggio non è valido perché indica una richiesta di build con una configurazione errata.

sourceProvenanceHash: imposta l'opzione sourceProvenanceHash per specificare l'algoritmo hash per la provenienza dell'origine. Il seguente snippet specifica che l'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: Cloud Build fornisce quattro tipi di macchine virtuali con CPU elevata per eseguire le build: due tipi di macchine con 8 CPU e due tipi di macchine con 32 CPU. Il tipo di macchina predefinito è 1 CPU. La richiesta di una macchina virtuale con CPU elevata può aumentare il tempo di avvio della tua build. Aggiungi l'opzione machineType per richiedere una macchina virtuale con una CPU più elevata:

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

Per ulteriori informazioni sull'opzione machineType, consulta la sezione Velocizzare le build.

diskSizeGb: Utilizza l'opzione diskSizeGb per richiedere una dimensione del disco personalizzata per la tua build. La dimensione massima che puoi richiedere è 1000 GB.

Il seguente snippet richiede una dimensione del disco di 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: utilizza questa opzione per specificare se vuoi creare un flusso dei log di build in Cloud Storage. Per impostazione predefinita, Cloud Build raccoglie i log di build al completamento della build; questa opzione specifica se vuoi creare un flusso di log di build in tempo reale durante il processo di compilazione. Lo snippet seguente specifica che i log di build vengono trasmessi in streaming a Cloud Storage:

YAML

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

JSON

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

logging: utilizza questa opzione per specificare se vuoi archiviare i log in Cloud Logging o Cloud Storage. Se non imposti questa opzione, Cloud Build archivia i log sia in Cloud Logging che in Cloud Storage. Puoi impostare l'opzione logging su GCS_ONLY per archiviare i log solo in Cloud Storage. Lo snippet seguente specifica che i log sono archiviati in 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"
    }
}

dynamic_substitutions: utilizza questa opzione per abilitare o disabilitare esplicitamente l'espansione dei parametri bash nelle sostituzioni. Se la tua build viene richiamata da un trigger, il campo dynamic_substitutions viene sempre impostato su true e non deve essere specificato nel tuo file di configurazione della build. Se la build viene richiamata manualmente, devi impostare il campo dynamic_substitutions su true in modo che le espansioni dei parametri bash vengano interpretate durante l'esecuzione della build.

substitutionOption: dovrai impostare questa opzione insieme al campo substitutions qui sotto per specificare il comportamento in caso di errore nei controlli di sostituzione.

pool: imposta il valore di questo campo sul nome della risorsa del pool privato per eseguire la build. Per istruzioni sull'esecuzione di una build su un pool privato, consulta Esecuzione delle build in un pool privato.

requestedVerifyOption: utilizza questa opzione per verificare la generazione di attestati e metadati di prove per la build. Questa opzione abilita anche attestazioni e metadati di provenienza per le build nei pool privati.

substitutions

Utilizza sostituzioni nel file di configurazione della build per sostituire variabili specifiche al momento della build. Le sostituzioni sono utili per le variabili il cui valore non è noto fino al momento della creazione o per riutilizzare una richiesta di build esistente con valori delle variabili diversi. Per impostazione predefinita, la build restituisce un errore se è presente una variabile di sostituzione mancante o di sostituzione. Tuttavia, puoi utilizzare l'opzione ALLOW_LOOSE per saltare questo controllo.

Il seguente snippet utilizza sostituzioni per stampare "hello world." L'opzione di sostituzione ALLOW_LOOSE è impostata, il che significa che la build non restituirà un errore se manca una variabile di sostituzione o se manca una sostituzione.

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

Per ulteriori istruzioni sull'utilizzo di substitutions, consulta Sostituzione dei valori delle variabili.

tags

Utilizza il campo tags per organizzare le build in gruppi e per filtrarle. La seguente configurazione imposta due tag denominati 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

Utilizza questo campo per utilizzare un secret di Secret Manager con Cloud Build. Per ulteriori informazioni, consulta Utilizzo dei secret.

secrets

Secret associa una serie di variabili di ambiente secret contenenti valori criptati con la chiave Cloud KMS da utilizzare per decriptare il valore.

serviceAccount

Utilizza questo campo per specificare l'account di servizio IAM da utilizzare al momento della creazione. Per ulteriori informazioni, consulta la sezione Configurare gli account di servizio specificati dall'utente.

images

Il campo images nel file di configurazione di compilazione specifica una o più immagini Docker che devono essere sottoposte a push da Cloud Build a Container Registry. Potresti avere una build che esegue attività senza produrre immagini Docker di Linux, ma se crei immagini e non le invii al Registro di sistema, le immagini vengono eliminate al completamento della build. Se non viene prodotta un'immagine specificata durante la build, quest'ultima avrà esito negativo. Per ulteriori informazioni sull'archiviazione delle immagini, consulta la sezione Archiviare gli artefatti delle build in Cloud Storage.

La seguente configurazione di compilazione imposta il campo images per archiviare l'immagine creata:

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

Il campo artifacts nel file di configurazione della build specifica uno o più artefatti non container da archiviare in Cloud Storage. Per ulteriori informazioni sull'archiviazione degli artefatti non containerizzati, consulta la sezione Archiviare gli artefatti delle build in Cloud Storage.

La seguente configurazione di compilazione imposta il campo artifacts per archiviare il pacchetto Go creato su 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"
        ]
      }
    }
}

Utilizzo dei Dockerfile

Se esegui build Docker in Cloud Build utilizzando l'interfaccia a riga di comando gcloud o i trigger di build, puoi utilizzare solo un elemento Dockerfile per creare l'immagine. Non è necessario un file di configurazione della build separato. Se vuoi apportare ulteriori modifiche alle build Docker, puoi fornire un file di configurazione della build oltre al Dockerfile. Per istruzioni su come creare un'immagine Docker utilizzando un Dockerfile, consulta la Guida rapida: build.

Rete Cloud Build

Quando Cloud Build esegue ogni passaggio di build, collega il container di questo passaggio a una rete Docker locale denominata cloudbuild. La rete cloudbuild ospita le credenziali predefinite dell'applicazione (ADC) che i servizi Google Cloud possono utilizzare per trovare automaticamente le tue credenziali. Se esegui container Docker nidificati e vuoi esporre ADC a un container sottostante o utilizzare gsutil o gcloud in un passaggio docker, utilizza il flag --network nel passaggio build del 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",
        "."
      ]
   }
  ]
}

Passaggi successivi