Un file di configurazione di compilazione contiene istruzioni per Cloud Build per eseguire attività in base alle tue specifiche. Ad esempio, il file di configurazione di compilazione può contenere istruzioni per creare, pacchettizzare ed eseguire il push di immagini Docker.
Questa pagina illustra lo schema del file di configurazione di Cloud Build. Per istruzioni su come creare e utilizzare un file di configurazione della build, consulta Creare 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 Build
dell'API Cloud Build.
Puoi scrivere il file della configurazione di compilazione 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, ...]
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)
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",
"..."
]
}
Ogni sezione del file di configurazione di compilazione definisce una parte dell'attività che vuoi che Cloud Build esegua:
Passi build
Un passaggio di build specifica un'azione che vuoi che Cloud Build esegua. Per ogni passaggio di build, Cloud Build esegue un container Docker come istanza di docker run
. I passaggi di compilazione sono analoghi ai comandi in uno script e ti offrono la flessibilità di eseguire istruzioni arbitrarie nella compilazione. Se puoi pacchettizzare uno strumento di compilazione in un contenitore,
Cloud Build può eseguirlo nell'ambito della compilazione. Per impostazione predefinita,
Cloud Build esegue tutti i passaggi di una build in sequenza sulla stessa macchina.
Se hai passaggi che possono essere eseguiti contemporaneamente, utilizza l'opzione waitFor.
Puoi includere fino a 300 passaggi di compilazione nel file di configurazione.
Utilizza il campo steps
nel file di configurazione della build per specificare un passaggio di compilazione. Ecco un frammento 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 compilazione per specificare un cloud
builder, ovvero un'immagine container che esegue strumenti comuni. Utilizzi un generatore in un passaggio di compilazione per eseguire le tue attività.
Lo snippet seguente mostra i passaggi di compilazione che chiamano i comandi
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 compilazione prende un elenco di argomenti e li passa al compilatore a cui fa riferimento il campo name
. Gli argomenti passati al generatore vengono passati allo strumento in esecuzione nel generatore, il che ti consente di richiamare qualsiasi comando supportato dallo strumento. Se il generatore utilizzato nel passaggio di compilazione ha un punto di entry, gli argomenti verranno utilizzati come argomenti per quel punto di entry. Se il compilatore
non definisce un punto di contatto, il primo elemento in args verrà utilizzato come
punto di contatto e il resto verrà utilizzato come argomenti.
Puoi creare fino a 100 argomenti per passaggio. La lunghezza massima dell'argomento è di 10.000 caratteri.
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 compilazione accetta 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 compilazione imposta la zona Compute Engine e il cluster GKE prima dell'esecuzionekubectl
:
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 contenitore del passaggio. Se imposti il campo dir
nel passaggio di compilazione,
la directory di lavoro viene impostata su /workspace/<dir>
. Se questo valore è un percorso relativo, si riferisce alla directory di lavoro della compilazione. Se questo valore è assoluto, potrebbe trovarsi al di fuori della directory di lavoro del build, nel qual caso i contenuti del percorso potrebbero non essere mantenuti nelle esecuzioni dei passaggi di compilazione (a meno che non sia specificato un volume per il percorso).
Il seguente snippet di codice imposta la directory di lavoro per il passaggio di compilazione 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 ha limiti di tempo e potrà essere eseguito fino al completamento o al timeout della compilazione stessa. Il campo timeout
in un passaggio di compilazione non deve superare il valore timeout
specificato per una compilazione. timeout
deve essere specificato in secondi con un massimo di nove cifre frazionarie, che termina con "s". Esempio: 3.5s
Nella seguente configurazione di compilazione, il timeout del passaggio ubuntu
si verifica 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 compilazione, non puoi specificare args
o entrypoint
nello stesso passaggio. Per istruzioni sull'utilizzo del campo script
, consulta
Eseguire script bash.
automapSubstitutions
Se impostato su true
, mappa automaticamente tutte le sostituzioni e le rende disponibili come variabili di ambiente in un unico passaggio. Se impostato su false
, ignora le sostituzione per quel passaggio. Per esempi, consulta Sostituisci i valori delle variabili.
ID
Utilizza il campo id
per impostare un identificatore univoco per un passaggio di compilazione. id
viene utilizzato con il campo waitFor
per configurare l'ordine in cui devono essere eseguiti i passaggi di compilazione. Per istruzioni sull'utilizzo di waitFor
e id
, consulta Configurare l'ordine dei passaggi di compilazione.
waitFor
Utilizza il campo waitFor
in un passaggio di compilazione per specificare i passaggi da eseguire prima del passaggio di compilazione. Se non vengono forniti valori per waitFor
, il passaggio di compilazione aspetta che tutti i passaggi di compilazione precedenti nella richiesta di compilazione vengano completati correttamente prima di essere eseguito. Per istruzioni sull'utilizzo di waitFor
e id
, consulta Configurare l'ordine dei passaggi di compilazione.
entrypoint
Utilizza entrypoint
in un passaggio di compilazione per specificare un punto di contatto se non vuoi utilizzare il punto di contatto predefinito del generatore. Se non imposti questo campo,
Cloud Build utilizzerà il punto di contatto del generatore. Lo snippet seguente imposta i punti di contatto per il passaggio di compilazione 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 utilizzando una chiave di crittografia Cloud KMS. Questi valori devono essere specificati nei secret della build. Per informazioni sull'utilizzo di questo campo, consulta Utilizzare la variabile criptata nelle richieste di compilazione.
volumes
Un
volume
è un volume del contenitore Docker montato nei passaggi di compilazione per mantenere i file
tra i passaggi di compilazione. Quando Cloud Build esegue un passaggio di build, monta automaticamente un volume workspace
in /workspace
. Puoi specificare volumi aggiuntivi da montare nei container dei passaggi di compilazione utilizzando il campo volumes
per i 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, che verrà eliminato prima dell'esecuzione del secondo passaggio. Se specifichi il volume con lo stesso nome in entrambi i passaggi, i contenuti di /persistent_volume
nel primo passaggio vengono mantenuti 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 compilazione, se imposti il valore del campo allowFailure
su true
e il passaggio di compilazione non va a buon fine, la compilazione va a buon fine a condizione che tutti gli altri passaggi di compilazione della compilazione vadano a buon fine.
Se per tutti i passaggi di compilazione di una build è impostato allowFailure
su true
e tutti i passaggi di compilazione non vanno a buon fine, lo stato della build rimane Successful
.
allowExitCodes
ha la precedenza su questo campo.
Il seguente snippet di codice consente il completamento della compilazione 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 di un passaggio di compilazione può essere ignorato quando il passaggio restituisce un determinato codice di uscita.
Se un passaggio di compilazione non va a buon fine con un codice di uscita corrispondente al valore che hai fornito in allowExitCodes
, Cloud Build consentirà il fallimento di questo passaggio senza che l'intera compilazione non vada a buon fine.
Se il 100% dei passaggi di compilazione non va a buon fine, ma ogni passaggio esce con un codice che hai specificato nel campo allowExitCodes
, la compilazione è comunque riuscita.
Tuttavia, se il passaggio di compilazione non va a buon fine e genera un altro codice di uscita, che non corrisponde al valore specificato in allowExitCodes
, la compilazione complessiva non andrà a buon fine.
I codici di uscita pertinenti alla compilazione dipendono dal software. Ad esempio, "1" è un codice di uscita comune in Linux. Puoi anche definire i tuoi codici di uscita negli script. Il campo allowExitCodes
accetta numeri fino a un massimo di 255.
Questo campo ha la precedenza su allowFailure
.
Il seguente snippet di codice consente il completamento della compilazione quando il primo passaggio non va a buon fine 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 compilazione per specificare il tempo di esecuzione della compilazione, con granularità in secondi. Se questo periodo di tempo scade, il lavoro sulla compilazione verrà interrotto e lo stato della compilazione sarà TIMEOUT
. Se timeout
non è impostato, alla compilazione verrà applicato un valore predefinito di 60 minuti per timeout
. Il valore massimo che può essere applicato a timeout
è di 24 ore. timeout
deve essere specificato in secondi con un massimo di nove cifre frazionarie, che termina con "s". Esempio: 3.5s
Nel seguente snippet, timeout
è impostato su 660 secondi per evitare che la compilazione superi il tempo di attesa 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 il periodo di tempo per cui una build può essere messa in coda. Se una compilazione è in coda per più tempo del valore impostato in queueTtl
, scade e lo stato della compilazione viene impostato su EXPIRED
. Se non viene fornito alcun valore, Cloud Build utilizza il valore predefinito di 3600s
(1 ora). queueTtl
inizia a ticchettare dal giorno createTime
. queueTtl
deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminanti con "s", ad esempio 3.5s
.
Nel seguente snippet, timeout
è impostato su 20s
e queueTtl
è impostato su 10s
.
queueTtl
inizia a ticchettare alle createTime
, ovvero nel momento in cui viene richiesta la compilazione, e timeout
inizia a ticchettare alle startTime
, ovvero nel momento in cui inizia la compilazione. Pertanto, queueTtl
scadrà alle ore createTime
+ 10s
, a meno che la compilazione 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 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.
Il seguente snippet imposta un bucket di log per archiviare i log di compilazione:
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 compilazione:
enableStructuredLogging
: consente la mappatura dei campi del log di compilazione specificati ai campi LogEntry
quando il log di compilazione viene inviato a Logging.
Ad esempio, se il log di compilazione contiene un message
, il messaggio viene visualizzato in textPayload
o jsonPayload.message
nella voce del log risultante. I campi di log non mappabili vengono visualizzati nella voce del logjsonPayload
. Per ulteriori informazioni, consulta la pagina su come mappare i campi del log di compilazione ai campi di voce del log.
env
:
un elenco di definizioni di variabili di ambiente globali esistenti per tutti i passaggi di compilazione di questa build. Se una variabile è definita sia a livello globale sia in un
passaggio di compilazione, utilizzerà il valore del passaggio di compilazione. Gli elementi sono del tipo
KEY=VALUE
per la variabile di ambiente KEY
a cui viene assegnato il valore VALUE
.
secretEnv
:
un elenco di variabili di ambiente globali, criptate utilizzando una chiave di crittografia di Cloud Key Management Service, che sarà disponibile per tutti i passaggi di compilazione in questa compilazione.
Questi valori devono essere specificati in Secret
della build.
volumes
:
un elenco di volumi da montare a livello globale per TUTTI i passaggi di compilazione. Ogni volume viene creato come volume vuoto prima di avviare il processo di compilazione. Al termine della compilazione, 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 compilazione. L'utilizzo di un volume globale in una compilazione con un solo passaggio non è valido in quanto indica una richiesta di compilazione con una configurazione errata.
sourceProvenanceHash
: imposta l'opzione sourceProvenanceHash
per specificare l'algoritmo di hash per l'origine della provenienza. Lo snippet seguente specifica che l'algoritmo di hashing è
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. Cloud Build offre inoltre altri due tipi di macchine virtuali con 1 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 più CPU 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'utilizzo dell'opzione machineType
, consulta Velocizzare le compilazioni.
diskSizeGb
:
utilizza l'opzione diskSizeGb
per richiedere una dimensione del disco personalizzata per la tua build. La dimensione massima che puoi richiedere è 4000 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 in streaming i log di compilazione su
Cloud Storage. Per impostazione predefinita, Cloud Build raccoglie i log di compilazione al termine della compilazione. Questa opzione specifica se vuoi eseguire lo streaming dei log di compilazione in tempo reale durante il processo di compilazione. Lo snippet seguente specifica che i log di compilazione 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 sia 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 vengono 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
ti consente di configurare Cloud Build per creare un bucket dei log predefinito all'interno del tuo progetto nella stessa regione della build. Per ulteriori informazioni, vedi Archiviare i log di compilazione in un bucket di proprietà dell'utente e regionalizzato.
La seguente configurazione di compilazione 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"
}
}
dynamicSubstitutions
:
utilizza questa opzione per attivare o disattivare esplicitamente
l'espansione dei parametri bash
nelle sostituzioni. Se la compilazione viene invocata da un trigger, il campodynamicSubstitutions
viene sempre impostato su true e non deve essere specificato nel file di configurazione della compilazione. Se la compilazione viene invocata manualmente, devi impostare il campo dynamicSubstitutions
su true affinché le espansioni dei parametri bash vengano interpretate durante l'esecuzione della compilazione.
automapSubstitutions
: mappa automaticamente tutte le sostituzioni alle variabili di ambiente che saranno disponibili per l'intera build. Per esempi, consulta
Sostituisci i valori delle variabili.
substitutionOption
:
imposta questa opzione insieme al campo substitutions
di seguito 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 in cui eseguire la compilazione. Per istruzioni su come eseguire una build in un pool privato, consulta
Eseguire le build in un pool privato.
requestedVerifyOption
:
imposta il valore di requestedVerifyOption
su VERIFIED
per attivare e verificare la
generazione di
attestazioni e
metadati di provenienza per
la tua compilazione. Una volta impostato, le build verranno contrassegnate come SUCCESS
solo se vengono generate attestazioni e provenienza.
substitutions
Utilizza le sostituzioni nel file di configurazione della build per sostituire variabili specifiche al momento della compilazione. Le sostituzioni sono utili per le variabili il cui valore non è noto fino al momento della compilazione o per riutilizzare una richiesta di compilazione esistente con valori di variabili diversi. Per impostazione predefinita, la compilazione restituisce un errore se manca una variabile di sostituzione o una sostituzione. Tuttavia, puoi utilizzare l'opzione ALLOW_LOOSE
per saltare questo controllo.
Lo snippet seguente utilizza le sostituzioni per stampare "hello world". L'opzione di sostituzione ALLOW_LOOSE
è impostata, il che significa che la compilazione non restituirà un errore se manca una variabile di sostituzione o 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 Sostituisci valori
variabili.
tags
Utilizza il campo tags
per organizzare le build in gruppi e 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 ulteriori informazioni, consulta la sezione Utilizzare i secret.
secrets
Secret abbina un insieme di variabili di ambiente segrete 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 compilazione. Per ulteriori informazioni, consulta la pagina sulla configurazione degli account di servizio specificati dall'utente.
images
Il campo images
nel file di configurazione di compilazione specifica una o più immagini Docker Linux da spingere da Cloud Build ad Artifact Registry o Container Registry (Ritirato). Potresti avere una build che esegue attività senza produrre immagini Docker Linux, ma se crei immagini e non le invii al registry, queste vengono eliminate al termine della build. Se un'immagine specificata non viene prodotta durante la compilazione, la compilazione non andrà a buon fine. Per ulteriori informazioni sull'archiviazione delle immagini, consulta Archiviare gli artefatti in Artifact Registry.
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 compilazione specifica uno o più
gli artefatti non contenitore da archiviare in Cloud Storage. Per ulteriori informazioni sull'archiviazione degli artefatti non del contenitore, consulta Archiviare gli artefatti della build in Cloud Storage.
La seguente configurazione di compilazione imposta il campo artifacts
per archiviare il pacchetto Go compilato in 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
Il campo goModules
ti consente di caricare moduli Go non contenitore nei repository Go in Artifact Registry. Per ulteriori informazioni, consulta
Creare e testare applicazioni Go.
Il campo repository_location
specifica il repository Artifact Registry
per archiviare i pacchetti. Il campo module_path
specifica la directory locale
che contiene il modulo Go da caricare. Questa directory deve contenere un
file go.mod
.
Ti consigliamo di utilizzare un percorso assoluto per il valore di module_path
. 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 module_path
, consulta
Creare e testare applicazioni Go.
La seguente configurazione di compilazione imposta il campo goModules
per caricare il modulo in example.com/myapp
nel repository Artifact Registryquickstart-go-repo
:
YAML
artifacts:
goModules:
repositoryName: 'quickstart-go-repo'
repositoryLocation: 'us-central1'
repositoryProject_id: 'argo-local-myname'
sourcePath: '/workspace/myapp'
modulePath: 'example.com/myapp'
moduleVersion: 'v1.0.0'
JSON
{
"artifacts": {
"goModules": {
"repositoryName": "quickstart-go-repo",
"repositoryLocation": "us-central1",
"repositoryProject_id": "argo-local-myname",
"sourcePath": "/workspace/myapp",
"modulePath": "example.com/myapp",
"moduleVersion": "v1.0.0"
}
}
}
mavenArtifacts
Il campo mavenArtifacts
ti consente di caricare artefatti Java non containerizzati nei repository Maven in Artifact Registry. Per ulteriori informazioni, consulta
Creare e testare applicazioni Java.
La seguente configurazione di build imposta il campo mavenArtifacts
per caricare il file pacchettizzato 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
ti consente di caricare i pacchetti Python in Artifact Registry.
Per ulteriori informazioni, consulta
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 compilati 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
.
Ti 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
, consulta Creare e testare applicazioni Node.js.
La seguente configurazione di compilazione imposta il campo npmPackages
per caricare il pacchetto npm nella directory /workspace/my-pkg
nel repository Artifact Registryhttps://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 utilizzando l'interfaccia a riga di comando gcloud o gli trigger di compilazione, puoi utilizzare un Dockerfile
senza un file di configurazione della build separato. Se vuoi apportare ulteriori modifiche alle tue compilazioni Docker, puoi fornire un file di configurazione di compilazione oltre a Dockerfile
. Per istruzioni su come creare un'immagine Docker utilizzando un
Dockerfile
, consulta la Guida rapida: compilazione.
Rete Cloud Build
Quando Cloud Build esegue ogni passaggio di build, collega il relativo
container a una rete Docker locale denominata cloudbuild
. La cloudbuild
rete ospita le credenziali predefinite dell'applicazione
(ADC) che i Google Cloud servizi possono utilizzare per trovare automaticamente le tue
credenziali. Se esegui container Docker nidificati e vuoi esporre
l'ADC a un container sottostante o utilizzare gcloud
in un passaggio docker
,
utilizza il flag --network
nel passaggio docker build
:
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 l'articolo Avvio manuale di una build per istruzioni su come eseguire le build in Cloud Build.