Schema del file di configurazione di compilazione

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Un file di configurazione di compilazione contiene le istruzioni per consentire a Cloud Build di eseguire attività in base alle tue specifiche. Ad esempio, il file di configurazione della build può contenere istruzioni per creare, pacchettizzare ed eseguire il push di immagini Docker.

Questa pagina spiega 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 Creazione di un file di configurazione della build di base.

Struttura di un file di configurazione della build

I file di configurazione della build vengono 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, utilizza 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",
        "..."
    ]
}

Ognuna delle sezioni del file di configurazione della build definisce una parte dell'attività che vuoi che Cloud Build esegua:

Passi build

Un passaggio di build specifica un'azione che vuoi venga eseguita da Cloud Build. Per ogni passaggio della build, Cloud Build esegue un container docker come istanza di docker run. I passaggi di build sono analoghi ai comandi di uno script e offrono la flessibilità di eseguire istruzioni arbitrarie nella build. Se puoi pacchettizzare uno strumento di compilazione 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 passaggi 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 cloud builder, ovvero un'immagine container che esegue strumenti comuni. Puoi 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 a cui fa riferimento il campo name. Gli argomenti passati al builder vengono passati allo strumento in esecuzione nel builder, che ti consente di 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 nelle aree geografiche verrà utilizzato come punto di ingresso e il resto verrà utilizzato come argomento.

Puoi creare fino a 100 argomenti per passaggio. La lunghezza massima dell'argomento è 4000.

Lo snippet seguente 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 utilizza un elenco di variabili di ambiente da utilizzare quando si esegue il passaggio. Le variabili sono nel formato KEY=VALUE.

Nella seguente configurazione di compilazione il campo env del passaggio di build imposta la zona Compute Engine e il cluster GKE prima dell'esecuzione di 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 build per impostare una directory di lavoro da utilizzare durante l'esecuzione del container del passaggio. Se imposti il campo dir nel passaggio di creazione, la directory di lavoro è impostata su /workspace/<dir>. Se questo valore è un percorso relativo, è relativo alla directory di lavoro della build. Se questo valore è assoluto, potrebbe non trovarsi nella directory di lavoro della build, nel qual caso i contenuti del percorso potrebbero non essere persistenti tra le esecuzioni dei passaggi di build (a meno che non venga specificato un volume per il percorso).

Il seguente snippet di codice imposta la directory di lavoro per il passaggio di build come /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 build per impostare un limite di tempo per l'esecuzione del passaggio. Se non imposti questo campo, il passaggio non ha limiti di tempo e ne verrà consentita l'esecuzione fino al completamento o fino 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, terminato da 's'. Esempio: 3.5s

Nella configurazione di compilazione seguente, il passaggio ubuntu è scaduto 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 build 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 pagina 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 di 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 build per specificare quali passaggi devono essere eseguiti prima di eseguire il passaggio di build. Se non sono specificati valori per waitFor, il passaggio di build attende che tutti i passaggi di build precedenti nella richiesta di build vengano completati correttamente prima dell'esecuzione. Per istruzioni sull'utilizzo di waitFor e id, consulta la sezione Configurazione dell'ordine dei passaggi di build.

entrypoint

Utilizza il entrypoint in un passaggio della build per specificare un punto di ingresso se non vuoi utilizzare il punto di ingresso predefinito del builder. Se non imposti questo campo, Cloud Build utilizzerà il punto di ingresso 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 che vengono 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 passi di build per rendere i file persistenti nei 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 di build' container utilizzando il campo volumes per i tuoi passaggi.

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 hanno specificato il percorso /persistent_volume come volume permanente, il primo passaggio scriverà il file in quel percorso, quindi il file verrà 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 sul 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 la quantità di tempo per cui l'esecuzione della build deve essere consentita, con una seconda granularità. Se questo tempo scade, il lavoro sulla build cesserà e lo stato della build sarà TIMEOUT. Se timeout non è impostato, alla build si applicherà un timeout predefinito 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, terminato da 's'. Esempio: 3.5s

Nello snippet seguente, il valore di timeout è impostato su 660 secondi per evitare che la build scada in timeout 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 in cui una build può essere messa in coda. Se una build è in coda più a lungo del valore impostato in queueTtl, la build scade e lo stato della build è impostato su EXPIRED. Se non viene specificato alcun valore, Cloud Build utilizza il valore predefinito di 3600s (1 ora). Il titolo queueTtl inizia a essere selezionato da createTime. queueTtl deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminato da 's', ad esempio 3.5s.

Nel seguente snippet, timeout è impostato su 20s e queueTtl è impostato su 10s. Il riquadro queueTtl inizia a essere selezionato su createTime, ossia l'ora in cui viene richiesta la build, mentre timeout inizia a essere selezionato su startTime, ossia l'ora in cui inizia la build. Pertanto, queueTtl scadrà il giorno createTime + 10s, a meno che la build non sia avviata entro tale 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 di 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 che esistono per tutti i passaggi di build in questa build. Se una variabile è definita sia a livello globale che in un passaggio di build, utilizzerà il valore del passaggio di build. Gli elementi sono nel formato KEY=VALUE per la variabile di ambiente KEY con il valore VALUE.

secretEnv: Un elenco di variabili di ambiente globali, criptate con una chiave di crittografia Cloud Management Service di Cloud Key, che saranno disponibili per tutti i passaggi di build in questa build. Questi valori devono essere specificati nel Secret della build.

volumes: Un elenco di volumi da montare a livello globale per TUTTI i passaggi della build. Ogni volume viene creato come volume vuoto prima dell'inizio del processo di compilazione. Al termine della build, i volumi e i relativi contenuti vengono eliminati. I nomi e i percorsi del volume globale non possono essere in conflitto con i volumi definiti un passaggio di build. L'utilizzo di un volume globale in una build con un solo passaggio non è valido in quanto 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 tue build: due tipi di macchina con 8 CPU e due tipi di macchina con 32 CPU. Il tipo di macchina predefinita è 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 build. La dimensione massima che puoi richiedere è 1000 GB.

Lo snippet che segue 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 trasmettere in streaming i 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 tramite il processo di compilazione. Lo snippet che segue 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 attivare o disattivare in modo esplicito l'espansione del parametro bash nelle sostituzioni. Se la build viene richiamata da un trigger, il campo dynamic_substitutions è sempre impostato su true e non deve essere specificato nel file di configurazione della build. Se la build viene richiamata manualmente, devi impostare il campo dynamic_substitutions su vero per far sì che le espansioni del parametro bash vengano interpretate durante l'esecuzione della build.

substitutionOption: Applicherai questa opzione insieme al campo substitutions in basso 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 di build in un pool privato.

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

substitutions

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

Lo snippet che segue utilizza le 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 una sostituzione mancante.

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 istruzioni aggiuntive sull'uso di substitutions, consulta Sostituzione dei valori delle variabili.

tags

Utilizza il campo tags per organizzare le build in gruppi e per filtrare le build. 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 saperne di più, consulta Utilizzo dei secret.

secrets

Secret accoppia un insieme 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 build. Per ulteriori informazioni, consulta Configurazione di account di servizio specificati dall'utente.

images

Il campo images nel file di configurazione della build specifica una o più immagini Docker di Linux di cui eseguire il push da Cloud Build a Container Registry. Puoi avere una build che esegue attività senza produrre immagini Docker Linux, ma se crei immagini e non le trasferisci al registro, le immagini vengono eliminate al completamento della build. Se non viene prodotta un'immagine specificata durante la build, quest'ultima non andrà a buon fine. Per ulteriori informazioni sull'archiviazione di immagini, consulta la sezione Archiviare artefatti di 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 containerizzati da archiviare in Cloud Storage. Per ulteriori informazioni sull'archiviazione di artefatti non containerizzati, consulta Archiviare gli artefatti della 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 stai eseguendo build Docker in Cloud Build usando l'interfaccia a riga di comando gcloud o i trigger di build, puoi usare solo una 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 del 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 oppure usi gsutil o gcloud in un passaggio docker, usa 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