Un file di configurazione di compilazione contiene le istruzioni per l'esecuzione di Cloud Build attività in base alle tue specifiche. Ad esempio, il file di configurazione della build contengono istruzioni per creare, pacchettizzare ed eseguire il push delle immagini Docker.
Questa pagina illustra lo schema di Cloud Build di configurazione del deployment. Per istruzioni su come creare e utilizzare un file di configurazione di compilazione, consulta la sezione Creazione di un file di configurazione della build di base.
Struttura di un file di configurazione di compilazione
I file di configurazione di Build vengono modellati utilizzando
Build
risorsa.
Puoi scrivere il file di configurazione di compilazione utilizzando la sintassi YAML o JSON. Se inviare richieste di build utilizzando strumenti HTTP di terze parti come curl, utilizzare a riga di comando.
Un file di configurazione di compilazione 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 di compilazione definisce una parte dell'attività vuoi che Cloud Build esegua:
Passi build
Un passaggio di build specifica un'azione che deve essere eseguita da Cloud Build
eseguire il deployment. Per ogni passaggio di build, Cloud Build esegue un container Docker
come un'istanza di docker run
. I passaggi di build sono analoghi ai comandi in una
e ti offre la flessibilità di eseguire istruzioni arbitrarie.
nella tua build. Se puoi pacchettizzare uno strumento
di build in un container,
Cloud Build può eseguirlo come parte della tua build. Per impostazione predefinita,
Cloud Build esegue tutti i passaggi di una build in modo seriale sulla stessa macchina.
Se ci sono passaggi che possono essere eseguiti contemporaneamente, utilizza l'opzione waitFor.
Nel file di configurazione puoi includere fino a 300 passaggi di build.
Utilizza il campo steps
nel file di configurazione di compilazione per specificare un passaggio di build. Ecco un
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, un'immagine container
con strumenti comuni. Puoi utilizzare un builder in un passaggio di build per eseguire le tue attività.
Lo snippet seguente mostra i passaggi di build che chiamano il
bazel
,
gcloud
e
Gli builder di 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 a
il builder a cui fa riferimento il campo name
. Gli argomenti passati al builder sono
passate allo strumento in esecuzione nello strumento di creazione, il che ti consente di richiamare qualsiasi
supportato dallo strumento. Se il builder utilizzato nel passaggio di build ha un valore
gli argomenti verranno utilizzati come argomenti per quel punto di ingresso. Se lo strumento
non definisce un punto di ingresso, il primo elemento negli argomenti verrà utilizzato come
il punto di ingresso, mentre il resto verrà utilizzato come argomenti.
Puoi creare fino a 100 argomenti per passaggio. La lunghezza massima dell'argomento è 10.000 caratteri.
Il seguente snippet richiama il comando docker build
e installa Maven
delle dipendenze:
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 richiede un elenco di variabili di ambiente da utilizzare
durante l'esecuzione del passaggio. Il formato delle variabili è KEY=VALUE
.
Nella configurazione di compilazione seguente, il campo env
del passaggio di build imposta la
La zona di 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 di build per impostare una directory di lavoro da usare quando
che esegue il container del passaggio. Se imposti il campo dir
nel passaggio di build,
la directory di lavoro è impostata su /workspace/<dir>
. Se questo valore è un valore relativo
percorso, è relativo alla directory di lavoro della build. Se questo valore è
assoluto, potrebbe trovarsi al di fuori della directory di lavoro della build, nel qual caso
i contenuti del percorso non possono essere mantenuti nelle esecuzioni del passaggio di build (a meno che non venga
volume per quel percorso).
Lo snippet di codice riportato di seguito 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
passaggio. Se non imposti questo campo, il passaggio non ha limiti di tempo e verrà
può essere eseguita fino al completamento o fino al tempo
di esecuzione della build
fuori. Il campo timeout
in un passaggio di build non deve superare timeout
specificato per una build. timeout
deve essere specificato in secondi con un massimo di
nove cifre frazionarie, terminate con "s". Esempio: 3.5s
Nella configurazione di compilazione seguente, il passaggio ubuntu
scade dopo 500 secondi:
YAML
steps:
- name: 'ubuntu'
args: ['sleep', '600']
timeout: 500s
- name: 'ubuntu'
args: ['echo', 'hello world, after 600s']
JSON
{
"steps": [
{
"name": "ubuntu",
"args": [
"sleep",
"600"
],
"timeout": "500s"
},
{
"name": "ubuntu",
"args": [
"echo",
"hello world, after 600s"
]
}
]
}
copione
Utilizza il campo script
in un passaggio di build per specificare uno script shell da eseguire in
per completare il 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
, vedi
Esecuzione degli script bash.
ID
Utilizza il campo id
per impostare un identificatore univoco per un passaggio di build. id
in uso
con il campo waitFor
per configurare l'ordine in cui devono essere eseguiti i passaggi di build
vengono eseguiti tutti i test delle unità. Per istruzioni sull'utilizzo di waitFor
e id
, consulta Configurazione del passaggio di build
ordine.
waitFor
Utilizza il campo waitFor
in un passaggio di build per specificare quali passaggi devono essere eseguiti prima
viene eseguito il passaggio di build. Se non vengono forniti valori per waitFor
, il passaggio di build
attende il completamento di tutti i passaggi di build precedenti nella richiesta di build
prima dell'esecuzione. Per istruzioni sull'utilizzo di waitFor
e id
, consulta Configurazione
passaggio di build
ordine.
entrypoint
Usa entrypoint
in un passaggio di build per specificare un punto di ingresso se non vuoi
per 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 criptate con Cloud KMS di crittografia. Questi valori devono essere specificati nei secret della build. Per informazioni sull'utilizzo di questo campo, consulta Utilizzo della variabile criptata nella build richieste.
volumes
R
Volume
è un volume di container Docker montato nei passaggi di build per rendere persistenti i file
nei vari passaggi di build. Quando Cloud Build esegue un passaggio di build,
monta un volume workspace
in /workspace
. Puoi specificare ulteriori
i volumi da montare nei passi di build dei container utilizzando volumes
per i passaggi.
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
/persistent_volume
come volume permanente, il primo passaggio scriverà
file in quel percorso, il file verrà eliminato prima del secondo passaggio
. Specificando il volume con lo stesso nome in entrambi i passaggi,
i contenuti di /persistent_volume
nel primo passaggio vengono resi persistenti fino al secondo
passaggio.
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 riesce a condizione che tutti gli altri passaggi di quella build vadano a buon fine.
Se tutti i passaggi di build in una build hanno allowFailure
impostato su true
e tutti i passaggi di build hanno esito negativo, lo stato della build è ancora Successful
.
allowExitCodes
ha la precedenza su questo campo.
Il seguente snippet di codice consente di completare la build in caso di errore del primo passaggio:
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 di build può essere ignorato quando quel passaggio restituisce un determinato codice di uscita.
Se un passaggio di build ha esito negativo con un codice di uscita corrispondente al valore che hai fornito in allowExitCodes
, Cloud Build consentirà l'esito negativo di questo passaggio di build senza danneggiare l'intera build.
Se il 100% dei passaggi della build non riesce, ma ogni passaggio viene chiuso con un codice che hai specificato nel campo allowExitCodes
, la build viene comunque completata.
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 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 alla build di riuscire 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
l'esecuzione deve essere consentita con una granularità al secondo. Se trascorso questo periodo di tempo, lavora sulla
la build cesserà e la build
sarà TIMEOUT
. Se il criterio timeout
non viene configurato, viene impostato un valore predefinito di timeout
di 60 minuti
verrà applicato alla build. Il valore massimo che può essere applicato a timeout
è
24 ore su 24. timeout
deve essere specificato in secondi con un massimo di nove frazionari
cifre, terminate da "s". Esempio: 3.5s
Nel seguente snippet, il valore timeout
è impostato su 660 secondi per evitare la build
di 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 per quanto tempo una build può essere messa in coda. Se
una build è in coda da più tempo del valore impostato in queueTtl
, la build
scade e la build
sia impostato su
EXPIRED
. Se non viene fornito alcun valore, Cloud Build utilizza il valore predefinito
3600s
(1 ora). queueTtl
inizia a titolare da createTime
. queueTtl
deve
essere specificato in secondi con un massimo di nove cifre frazionarie, terminati con "s",
ad esempio 3.5s
.
Nel seguente snippet il valore timeout
è impostato su 20s
e queueTtl
è impostato su 10s
.
Il numero di queueTtl
inizia alle ore createTime
, ovvero il momento in cui viene creata
e timeout
inizia a ticchettio alle startTime
, che è l'ora in cui
viene avviata la build. Pertanto, queueTtl
scadrà il giorno createTime
+ 10s
a meno che
a partire da quella data.
YAML
steps:
- name: 'ubuntu'
args: ['sleep', '5']
timeout: 20s
queueTtl: 10s
JSON
{
"steps": [
{
"name": "ubuntu",
"args": [
"sleep",
"5"
]
}
],
"timeout": "20s",
"queueTtl": "10s"
}
logsBucket
Imposta il campo logsBucket
per una build 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 in cui 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 la options
per specificare i seguenti argomenti facoltativi per la tua build:
env
:
Un elenco di definizioni delle variabile di ambiente globali che esisteranno per tutte le build
passaggi in questa build. Se una variabile è definita sia a livello globale che in una build
la variabile utilizzerà il valore del passaggio di build. Gli elementi hanno questo formato
A KEY=VALUE
per la variabile di ambiente KEY
viene assegnato il valore VALUE
.
secretEnv
:
Un elenco di variabili di ambiente globali, criptate con Cloud Key Management
Chiave di crittografia del servizio, che sarà disponibile per tutti i passaggi di build in questa build.
Questi valori devono essere specificati nel valore 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. Una volta completata la
build, i volumi e i relativi contenuti
vengono ignorati. Nomi e percorsi dei volumi globali
non può essere in conflitto con i volumi definiti in un passaggio di build. L'utilizzo di un volume globale in
una build con un solo passaggio non è valida perché indica una richiesta di build con un
configurazione errata.
sourceProvenanceHash
:
Imposta l'opzione sourceProvenanceHash
per specificare l'algoritmo hash per l'origine
provenienza. Lo snippet riportato di seguito 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 con 32 CPU. Cloud Build
fornisce due tipi di macchine virtuali aggiuntive con 1 CPU e 2 CPU per eseguire le tue 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ù alta:
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 Accelerazione
le build.
diskSizeGb
:
Utilizza l'opzione diskSizeGb
per richiedere una dimensione del disco personalizzata per la tua build. La
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 eseguire il flusso dei log di build
di archiviazione ideale in Cloud Storage. Per impostazione predefinita, Cloud Build raccoglie i log di build
il completamento della build; questa opzione specifica se vuoi trasmettere i log di build in tempo reale
durante il processo di compilazione. Lo snippet seguente specifica che i log di build
vengono trasmesse in flussi 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
e archivia i log sia in Cloud Logging che in Cloud Storage. Puoi
imposta l'opzione logging
su GCS_ONLY
per archiviare i log solo in
di archiviazione ideale 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"
}
}
defaultLogsBucketBehavior
:
L'opzione defaultLogsBucketBehavior
consente di configurare Cloud Build per creare un bucket di log predefinito all'interno del tuo progetto, nella stessa regione della build. Per maggiori informazioni, vedi 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 in modo esplicito
espansione dei parametri con 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
imposta il campo dynamic_substitutions
su true per le espansioni del parametro bash su
da interpretare durante l'esecuzione della build.
substitutionOption
:
Imposterai questa opzione insieme al campo substitutions
di seguito per specificare il
comportamento quando si verifica un errore di sostituzione
controlli.
pool
:
Imposta il valore di questo campo sul nome della risorsa del pool privato da eseguire
la creazione. Per istruzioni sull'esecuzione di una build su un pool privato, consulta
Esecuzione delle build in un pool privato.
requestedVerifyOption
:
Imposta il valore di requestedVerifyOption
su VERIFIED
per attivare e verificare il
generazione di
attestati e
metadati di provenienza per
la tua build. Una volta configurate, le build verranno contrassegnate solo come SUCCESS
se vengono generate attestazioni e provenienza.
substitutions
Utilizza le sostituzioni nel file di configurazione della build per sostituire variabili specifiche in
in fase di creazione. Le sostituzioni sono utili per le variabili il cui valore è ignoto
fino alla fase di compilazione o per riutilizzare una richiesta di build esistente con variabili diverse
e i relativi valori. Per impostazione predefinita, la build restituisce un errore se manca una sostituzione
o una sostituzione mancante. Tuttavia, puoi utilizzare l'opzione ALLOW_LOOSE
.
per saltare questo controllo.
Lo snippet seguente utilizza le sostituzioni per stampare "Hello World". La
L'opzione di sostituzione ALLOW_LOOSE
è impostata, pertanto la build non verrà restituita
un errore se è presente 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'utilizzo di substitutions
, consulta Sostituzione di una variabile
predefiniti.
tags
Usa il campo tags
per organizzare le build in gruppi e filtrare
le build. La
la seguente configurazione imposta due tag denominati mytag1
e mytag2
:
YAML
steps:
- name: 'gcr.io/cloud-builders/docker'
...
- name: 'ubuntu'
...
tags: ['mytag1', 'mytag2']
JSON
{
"steps": [
{
"name": "gcr.io/cloud-builders/docker"
},
{
"name": "ubuntu"
}
],
"tags": [
"mytag1",
"mytag2"
]
}
availableSecrets
Utilizza questo campo per utilizzare un secret di Secret Manager con Cloud Build. Per ulteriori informazioni, consulta Utilizzo dei secret.
secrets
Il secret abbina un insieme di variabili di ambiente secret contenenti con la 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 ulteriori informazioni, vedi Configurazione di account di servizio specificati dall'utente.
images
Il campo images
nel file di configurazione di compilazione specifica uno o più Docker Linux
di cui Cloud Build esegue il push su Artifact Registry o Container Registry
(Deprecato). Potresti avere una build che esegue attività senza
producendo immagini Docker Linux, ma se crei immagini e non ne esegui il push
al registro, le immagini vengono ignorate al completamento della build. Se viene specificato
non viene prodotta durante la build, la build non riuscirà. Per maggiori informazioni
informazioni sull'archiviazione delle immagini, vedi
Archivia gli artefatti in Artifact Registry.
La seguente configurazione di build imposta il campo images
in cui 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 una o più
artefatti non containerizzati da archiviare in Cloud Storage. Per ulteriori informazioni
per l'archiviazione di artefatti non containerizzati, consulta Archiviare gli artefatti di build in Cloud Storage.
La seguente configurazione di build imposta il campo artifacts
in cui archiviare i contenuti Go creati
pacco per 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
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 compilazione 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 pacchetti Python in Artifact Registry. Per saperne di più, 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
ha creato pacchetti npm nei repository supportati in Artifact Registry. Devi
fornisce i valori per repository
e packagePath
.
Il campo repository
specifica il repository Artifact Registry in cui archiviare le tue
. Il campo packagePath
specifica la directory locale che
il pacchetto npm da caricare. Questa directory deve contenere un file package.json
.
Ti consigliamo di utilizzare un percorso assoluto per il valore packagePath
. Puoi utilizzare
.
per fare riferimento alla directory di lavoro attuale, 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 build imposta il campo npmPackages
per caricare il file npm
pacchetto nella directory /workspace/my-pkg
al 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 di Docker in Cloud Build utilizzando
gcloud CLI o trigger di build, puoi utilizzare un'istruzione Dockerfile
senza un file di configurazione di compilazione 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: Build.
Rete Cloud Build
Quando Cloud Build esegue ogni passaggio di build, collega il token
del container a una rete Docker locale denominata cloudbuild
. cloudbuild
host di rete Credenziali predefinite dell'applicazione
(ADC) che i servizi Google Cloud possono usare per trovare automaticamente
e credenziali. Se esegui container Docker nidificati e vuoi esporre
ADC a un container sottostante o utilizzare gcloud
in un passaggio docker
,
usa il flag --network
nel passaggio build
della finestra 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 una configurazione build di base file in e configurare le build per Cloud Build.
- Leggi Avvio di una build Manualmente per istruzioni su come eseguire le build in Cloud Build.