Un file di configurazione di compilazione contiene istruzioni che consentono a Cloud Build di eseguire attività basate sulle tue specifiche. Ad esempio, il file di configurazione di build può contenere istruzioni per creare, pacchettizzare ed eseguire il push delle immagini Docker.
Questa pagina descrive lo schema del file di configurazione di Cloud Build. Per istruzioni sulla creazione e sull'utilizzo di un file di configurazione della build, consulta la sezione Creazione di un file di configurazione di base.
Struttura di un file di configurazione della build
I file di configurazione di build sono modellati utilizzando la risorsa Build
dell'API Cloud 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, ...]
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
- 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)
defaultLogsBucketBehavior: enum(DefaultLogsBucketBehavior)
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)
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"
},
{
"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)"
"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)",
"mavenArtifacts": ["object(MavenArtifact)", ...],
"pythonPackages": ["object(PythonPackage)", ...],
"npmPackages": ["object(npmPackage)", ...],
"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 che venga eseguita da Cloud Build. Per ogni passaggio di build, Cloud Build esegue un container Docker come istanza di docker run
. I passaggi di build sono simili ai comandi in uno script e offrono la flessibilità di eseguire istruzioni arbitrarie nella build. Se puoi pacchettizzare uno strumento di creazione 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 esistono passaggi che possono essere eseguiti contemporaneamente, utilizza l'opzione waitFor.
Puoi includere fino a 300 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 cloud builder, ovvero un'immagine container che esegue strumenti comuni. Utilizzi un builder in un passaggio di build per eseguire le tue attività.
Lo snippet seguente mostra i passaggi di build che chiamano gli sviluppatori
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 accetta 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 generatore, in modo da poter richiamare qualsiasi comando supportato dallo strumento. Se il generatore utilizzato nel passaggio di creazione ha un
entrypoint, gli argomenti verranno utilizzati come argomenti per tale punto di ingresso. Se il builder non definisce un punto di ingresso, il primo elemento negli argomenti verrà utilizzato come punto di ingresso, mentre il resto come argomenti.
Puoi creare fino a 100 argomenti per passaggio. La lunghezza massima dell'argomento è 10.000 caratteri.
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 contiene un elenco di variabili di ambiente da utilizzare
durante l'esecuzione del passaggio. Le variabili sono nel formato KEY=VALUE
.
Nella seguente configurazione di build, il campo env
del passaggio di build imposta la zona Compute Engine e il cluster GKE prima dell'esecuzione
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 della build per impostare una directory di lavoro da utilizzare per l'esecuzione del container del passaggio. Se imposti il campo dir
nel passaggio della build, la directory di lavoro viene impostata su /workspace/<dir>
. Se questo valore è un percorso relativo, farà riferimento alla directory di lavoro della build. Se questo valore è assoluto, potrebbe essere al di fuori della directory di lavoro della build, nel qual caso i contenuti del percorso potrebbero non essere resi persistenti in tutte le 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 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 della 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 potrà essere eseguito 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, terminate con una "s". Esempio: 3.5s
Nella seguente configurazione di build, 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 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 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 eseguire i passi di build. Per istruzioni sull'utilizzo di waitFor
e id
, consulta Configurazione dell'ordine dei passaggi
delle build.
waitFor
Utilizza il campo waitFor
in un passaggio di build per specificare quali passaggi devono essere eseguiti prima
di quello di build. Se non vengono forniti 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 Configurazione dell'ordine dei passaggi della build.
entrypoint
Utilizza entrypoint
in un passaggio della build per specificare un punto di ingresso se non vuoi utilizzare quello predefinito del builder. Se non imposti questo campo,
Cloud Build utilizzerà il punto di ingresso del builder. Lo snippet seguente 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 mediante 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 nei passi di build per rendere persistenti i file
tra i vari 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 container dei passi di build utilizzando il campo volumes
per i tuoi passi.
Ad esempio, il seguente file di configurazione di compilazione scrive un file in un volume nel primo passaggio e lo legge nel secondo. Se in questi passaggi non è stato specificato il percorso /persistent_volume
come volume permanente, il primo passaggio scriverebbe 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 anche nel 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"
]
}
]
}
allowFailure
In un passaggio di build, se imposti il valore del campo allowFailure
su true
e il passaggio di build non riesce, la build ha esito positivo purché tutti gli altri passaggi della build abbiano esito positivo.
Se il criterio allowFailure
è impostato su true
in tutti i passaggi di una build e tutti i passaggi hanno esito negativo, lo stato della build è ancora Successful
.
allowExitCodes
ha la precedenza su questo campo.
Il seguente snippet di codice consente la corretta esecuzione della build quando il primo passaggio non va a buon fine:
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
Utilizza il campo allowExitCodes
per specificare che un errore del passaggio della build può essere ignorato quando il passaggio restituisce un determinato codice di uscita.
Se un passaggio di build ha esito negativo con un codice di uscita corrispondente al valore fornito in allowExitCodes
, Cloud Build consentirà l'esecuzione di questo passaggio di build senza causare errori nell'intera build.
Se il 100% dei passaggi della build non riesce, ma ogni passaggio termina con un codice specificato nel campo allowExitCodes
, la build ha comunque esito positivo.
Tuttavia, se il passaggio di build ha esito negativo e produce un altro codice di uscita (uno che non corrisponde al valore specificato in allowExitCodes
), la build complessiva avrà esito negativo.
I codici di uscita pertinenti alla build dipendono dal software. Ad esempio, "1" è un codice di uscita comune in Linux. Puoi anche definire codici di uscita personalizzati negli script. Il campo allowExitCodes
accetta numeri fino a un massimo di 255.
Questo campo ha la precedenza su allowFailure
.
Lo snippet di codice riportato di seguito consente la corretta esecuzione della build quando il primo passaggio non riesce con uno dei codici di uscita forniti:
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
Utilizza il campo timeout
per una build per specificare per quanto tempo deve essere consentita l'esecuzione della build, fino al secondo livello di granularità. Una volta trascorso questo tempo, 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 60 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 da "s". Esempio: 3.5s
Nello snippet seguente, timeout
è impostato su 660 secondi per evitare il timeout della build a causa della sospensione:
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 per quanto tempo una build può essere messa in coda. Se una build rimane in coda per un periodo superiore al valore impostato in queueTtl
, la build scade e lo stato della build è impostato su EXPIRED
. Se non viene fornito alcun valore, Cloud Build utilizza il valore predefinito di 3600s
(1 ora). queueTtl
inizierà a ticchettiare dalle ore createTime
. queueTtl
deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminate con una "s", ad esempio 3.5s
.
Nel seguente snippet, timeout
è impostato su 20s
, mentre queueTtl
è impostato su 10s
.
Il valore di queueTtl
inizia alle ore createTime
, ovvero quelle in cui viene richiesta
la build, mentre timeout
inizia alle ore startTime
, ovvero al momento in cui inizia la
build. Di conseguenza, queueTtl
scadrà alle ore createTime
+ 10s
, a meno che
la build non inizi entro questa 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 per 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 delle variabile di ambiente globali che saranno disponibili per tutti i passaggi
di questa build. Se una variabile viene 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
a cui è stato assegnato il valore VALUE
.
secretEnv
:
un elenco di variabili di ambiente globali, criptate mediante una chiave di crittografia di Cloud Key Management
Service, che sarà disponibile per tutti i passaggi della 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 di 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 entrare 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, in quanto indica una richiesta di build con una configurazione non corretta.
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 offre 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. Cloud Build offre inoltre due tipi di macchine virtuali aggiuntivi con 1 CPU e 2 CPU per eseguire le build. Il tipo di macchina predefinito è e2-standard-2
con 2 CPU.
La richiesta di una macchina virtuale con CPU elevata può aumentare il tempo di avvio della 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'utilizzo dell'opzione machineType
, consulta la pagina relativa all'accelerazione delle build.
diskSizeGb
:
utilizza l'opzione diskSizeGb
per richiedere una dimensione del disco personalizzata per la tua build. La dimensione massima che puoi richiedere è di 2000 GB.
Lo snippet seguente 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 i flussi di log delle build a
Cloud Storage. Per impostazione predefinita, Cloud Build raccoglie i log di build al completamento della build. Questa opzione specifica se vuoi trasmettere i flussi di log di build in tempo reale attraverso il processo di compilazione. Il seguente snippet specifica che i log di build vengono trasmessi 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. Il seguente snippet 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"
}
}
defaultLogsBucketBehavior
:
l'opzione defaultLogsBucketBehavior
consente di configurare Cloud Build in modo da creare un bucket di log predefinito all'interno del tuo progetto nella stessa regione della build. Per saperne di più, consulta Archiviare i log di build in un bucket di proprietà dell'utente e regionalizzato.
La seguente configurazione di build imposta il campo defaultLogsBucketBehavior
sul valore 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"
}
}
dynamic_substitutions
:
utilizza questa opzione per attivare o disattivare esplicitamente l'espansione dei parametri bash
nelle sostituzioni. Se la tua 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 true affinché le espansioni dei parametri bash vengano interpretate durante l'esecuzione della build.
substitutionOption
:
imposti questa opzione insieme al campo substitutions
di seguito per specificare il comportamento quando si verifica un 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
:
imposta il valore di requestedVerifyOption
su VERIFIED
per verificare la generazione di
attestations e
metadati di prova
per la build. Questa opzione abilita anche i metadati di attestazioni e provenienza per build e build a livello di regione nei pool privati. Se non aggiungi requestedVerifyOption: VERIFIED
, Cloud Build genera la provenienza solo per le build globali.
substitutions
Utilizza le sostituzioni nel file di configurazione della build per sostituire variabili specifiche in fase di compilazione. Le sostituzioni sono utili per le variabili il cui valore non è noto fino al momento della compilazione oppure per riutilizzare una richiesta di build esistente con valori di variabili diversi. Per impostazione predefinita, la build restituisce un errore in caso di variabile o sostituzione mancante. Tuttavia, puoi utilizzare l'opzione ALLOW_LOOSE
per saltare questo controllo.
Lo snippet seguente utilizza delle sostituzioni per stampare "Hello World". L'opzione di sostituzione ALLOW_LOOSE
è impostata, pertanto la build non restituirà un errore in caso di variabile o 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 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
configurazione seguente 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, vedi Utilizzare i secret.
secrets
Il Secret accoppia un insieme di variabili di ambiente secret contenenti valori criptati alla chiave Cloud KMS da utilizzare per decriptare il valore.
serviceAccount
Utilizza questo campo per specificare l'account di servizio IAM da utilizzare in fase di creazione. Per maggiori informazioni, consulta Configurazione degli account di servizio specificati dall'utente.
images
Il campo images
nel file di configurazione della build specifica una o più immagini Docker Linux che devono essere inviate da Cloud Build ad Artifact Registry o Container Registry
(Deprecato). Potresti avere una build che esegue attività senza
generare alcuna immagine Docker Linux, ma se crei immagini e non ne esegui il push
al registro, le immagini vengono eliminate al completamento della build. Se durante la build non viene prodotta un'immagine specificata, la build avrà esito negativo. Per ulteriori informazioni sull'archiviazione delle immagini, consulta Archiviare gli artefatti in Artifact Registry.
La seguente configurazione di build 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 di artefatti non containerizzati, consulta Archiviare gli artefatti delle build in Cloud Storage.
La seguente configurazione di build 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"
]
}
}
}
mavenArtifacts
Il campo mavenArtifacts
consente di caricare artefatti Java non containerizzati nei repository Maven in Artifact Registry. Per saperne di più, vedi Creare e testare applicazioni Java.
La seguente configurazione di build imposta il campo mavenArtifacts
per caricare il file in pacchetto my-app-1.0-SNAPSHOT.jar
nel repository 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
Il campo pythonPackages
consente di caricare pacchetti Python in Artifact Registry. Per saperne di più, vedi Creare e testare applicazioni Python.
La seguente configurazione di compilazione imposta il campo pythonPackages
per caricare il pacchetto Python dist/my-pkg.whl
nel repository 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
Utilizza il campo npmPackages
per configurare Cloud Build in modo da caricare i pacchetti npm creati nei repository supportati in Artifact Registry. Devi
fornire valori per repository
e packagePath
.
Il campo repository
specifica il repository Artifact Registry in cui archiviare i pacchetti. Il campo packagePath
specifica la directory locale che contiene il pacchetto npm da caricare. Questa directory deve contenere un file package.json
.
Consigliamo di utilizzare un percorso assoluto per il valore di packagePath
. Puoi utilizzare .
per fare riferimento alla directory di lavoro corrente, ma il campo non può essere omesso o lasciato vuoto. Per ulteriori istruzioni sull'utilizzo di npmPackages
, vedi Creare e testare applicazioni Node.js.
La configurazione di build seguente imposta il campo npmPackages
per caricare il pacchetto npm nella directory /workspace/my-pkg
nel repository 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"
}
]
}
}
Utilizzo dei Dockerfile
Se esegui build Docker in Cloud Build mediante gcloud CLI o trigger di build, puoi utilizzare Dockerfile
senza un file di configurazione della build separato. Se vuoi apportare ulteriori modifiche alle build Docker, puoi fornire un file di configurazione della build oltre a Dockerfile
. Per istruzioni su come creare un'immagine Docker utilizzando un Dockerfile
, consulta Guida rapida: creazione.
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 o utilizzare gsutil
o gcloud
in un passaggio docker
, utilizza il flag --network
nel passaggio build
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
- Scopri come creare un file di configurazione della build di base per configurare le build per Cloud Build.
- Leggi Avvio manuale di una build per istruzioni su come eseguire le build in Cloud Build.