Un fichier de configuration de compilation contient des instructions permettant à Cloud Build d'effectuer des tâches suivant vos spécifications. Par exemple, votre fichier de configuration de compilation peut contenir des instructions permettant de compiler, empaqueter et envoyer des images Docker.
Cette page explique le schéma du fichier de configuration Cloud Build. Pour obtenir des instructions sur la création et l'utilisation d'un fichier de configuration de compilation, consultez la section Créer un fichier de configuration de compilation de base.
Structure d'un fichier de configuration
Les fichiers de configuration de compilation sont modélisés à l'aide de la ressource Build
de l'API Cloud Build.
Vous pouvez écrire le fichier de configuration de compilation en utilisant la syntaxe YAML ou JSON. Si vous envoyez des demandes de compilation à l'aide d'outils http tiers tels que curl, utilisez la syntaxe JSON.
Un fichier de configuration de compilation a la structure suivante :
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)
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)",
"mavenArtifacts": ["object(MavenArtifact)", ...],
"pythonPackages": ["object(PythonPackage)", ...],
"npmPackages": ["object(npmPackage)", ...],
"images": [
"string",
"string",
"..."
]
}
Chacune des sections du fichier de configuration de compilation définit une partie de la tâche que vous souhaitez que Cloud Build exécute :
Étapes de compilation
Une étape de compilation spécifie une action que vous souhaitez que Cloud Build exécute. Pour chaque étape de compilation, Cloud Build exécute un conteneur Docker en tant qu'instance de docker run
. Les étapes de compilation sont semblables aux commandes d'un script et vous offrent la possibilité d'exécuter des instructions arbitraires dans votre compilation. Si vous pouvez intégrer un outil de compilation dans un conteneur, Cloud Build est en mesure de l'exécuter dans le cadre de la compilation. Par défaut, Cloud Build exécute toutes les étapes d'une compilation en série sur la même machine.
Si certaines étapes peuvent s'exécuter simultanément, utilisez l'option waitFor.
Vous pouvez inclure jusqu'à 300 étapes de compilation dans votre fichier de configuration.
Utilisez le champ steps
du fichier de configuration de compilation afin de spécifier une étape de compilation. Voici un extrait de code du type de configuration que vous pouvez définir dans le champ 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
Utilisez le champ name
d'une étape de compilation pour spécifier un compilateur Cloud, qui est une image de conteneur exécutant des outils communs. Vous utilisez un compilateur dans une étape de compilation pour exécuter vos tâches.
L'extrait de code suivant montre les étapes de compilation appelant les compilateurs bazel
, gcloud
et 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
Le champ args
d'une étape de compilation prend une liste d'arguments et la transmet au compilateur auquel le champ name
fait référence. Les arguments transmis au compilateur sont transmis à l'outil en cours d'exécution dans le compilateur, ce qui vous permet d'appeler n'importe quelle commande compatible avec l'outil. Si le compilateur utilisé dans l'étape de compilation a un point d'entrée, les arguments seront utilisés comme arguments au niveau de ce point d'entrée. Si le constructeur ne définit aucun point d'entrée, le premier élément de args sera utilisé comme point d'entrée et le reste comme arguments.
Vous pouvez créer jusqu'à 100 arguments par étape. La longueur maximale de l'argument est de 10 000 caractères.
L'extrait de code suivant appelle la commande docker build
et installe les dépendances 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
Le champ env
d'une étape de compilation prend une liste de variables d'environnement à utiliser lors de l'exécution de l'étape. Les variables sont au format KEY=VALUE
.
Dans la configuration de compilation suivante, le champ env
de l'étape de compilation définit la zone Compute Engine et le cluster GKE avant d'exécuter 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
Utilisez le champ dir
dans une étape de compilation pour définir un répertoire de travail à utiliser lors de l'exécution du conteneur de l'étape. Si vous définissez le champ dir
dans l'étape de compilation, le répertoire de travail est défini sur /workspace/<dir>
. Si cette valeur est un chemin relatif, elle est relative au répertoire de travail de la compilation. Si cette valeur est absolue, elle peut se trouver en dehors du répertoire de travail de la compilation, auquel cas le contenu du chemin ne peut pas être conservé lors des exécutions des étapes de compilation (à moins qu'un volume ne soit spécifié pour ce chemin).
L'extrait de code suivant définit le répertoire de travail pour l'étape de compilation comme /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
Utilisez le champ timeout
dans une étape de compilation pour définir une limite de temps pour l'exécution de l'étape. Si vous ne définissez pas ce champ, l'étape n'a pas de délai d'expiration et elle pourra continuer à s'exécuter jusqu'à ce qu'elle soit terminée ou que la compilation elle-même atteigne un délai d'expiration. Le champ timeout
d'une étape de compilation ne doit pas dépasser la valeur timeout
spécifiée pour une compilation. La valeur timeout
doit être exprimé en secondes, comprendre un maximum de neuf chiffres décimaux et se terminer par "s". Exemple : 3.5s
Dans la configuration de compilation suivante, l'étape ubuntu
expire au bout de 500 secondes :
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
Utilisez le champ script
dans une étape de compilation pour spécifier un script shell à exécuter dans l'étape. Si vous spécifiez script
dans une étape de compilation, vous ne pouvez pas spécifier args
ou entrypoint
dans la même étape. Pour obtenir des instructions sur l'utilisation du champ script
, consultez
Exécuter des scripts bash
automapSubstitutions
Si la valeur est true
, toutes les substitutions sont mappées automatiquement et sont disponibles en tant que variables d'environnement en une seule étape. Si défini sur false
, ignore les substitutions pour cette étape. Pour obtenir des exemples, consultez la section Remplacer les valeurs des variables.
id
Utilisez le champ id
afin de définir un identifiant unique pour une étape de compilation. id
est utilisé avec le champ waitFor
pour configurer l'ordre dans lequel les étapes de compilation doivent être exécutées. Pour obtenir des instructions sur l'utilisation de waitFor
et de id
, consultez la section Configurer l'ordre des étapes de compilation.
waitFor
Utilisez le champ waitFor
dans une étape de compilation pour spécifier les étapes à réaliser avant l'exécution de l'étape de compilation. Si aucune valeur n'est fournie pour le champ waitFor
, l'étape de compilation attend que toutes les étapes de compilation précédentes dans la requête de compilation soient terminées avant de s'exécuter. Pour obtenir des instructions sur l'utilisation de waitFor
et de id
, consultez la section Configurer l'ordre des étapes de compilation.
entrypoint
Utilisez entrypoint
dans une étape de compilation pour spécifier un point d'entrée si vous ne souhaitez pas utiliser le point d'entrée par défaut du compilateur. Si vous ne définissez pas ce champ, Cloud Build utilisera le point d'entrée du compilateur. L'extrait de code suivant définit les points d'entrée pour l'étape de compilation 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
Liste de variables d'environnement chiffrées à l'aide d'une clé de chiffrement Cloud KMS. Ces valeurs doivent être définies dans les codes secrets de la compilation. Pour plus d'informations sur l'utilisation de ce champ, consultez la section Utiliser la variable chiffrée dans les demandes de compilation.
volumes
Un Volume est un conteneur Docker installé dans des étapes de compilation pour conserver des fichiers entre les étapes de compilation. Lorsque Cloud Build exécute une étape de compilation, il installe automatiquement un volume workspace
dans /workspace
. Vous pouvez définir des volumes supplémentaires à installer dans les conteneurs de vos étapes de compilation à l'aide du champ volumes
de vos étapes.
Par exemple, le fichier de configuration de compilation suivant crée un fichier dans un volume lors de la première étape et le lit à la deuxième étape. Si ces étapes ne spécifient pas le chemin /persistent_volume
comme étant un volume persistant, la première étape écrit le fichier au niveau de ce chemin. Ce fichier est ensuite supprimé avant l'exécution de la deuxième étape. Spécifiez un volume portant le même nom dans les deux étapes pour que le contenu de /persistent_volume
de la première étape soit conservé à la deuxième étape.
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
Dans une étape de compilation, si vous définissez la valeur du champ allowFailure
sur true
et que l'étape de compilation échoue, la compilation réussit tant que toutes les autres étapes de cette compilation réussissent.
Si allowFailure
est défini sur true
pour toutes les étapes de compilation d'un build et que toutes les étapes échouent, l'état du build reste Successful
.
allowExitCodes
est prioritaire sur ce champ.
L'extrait de code suivant permet à la compilation de réussir en cas d'échec de la première étape:
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
Utilisez le champ allowExitCodes
pour spécifier qu'un échec d'une étape de compilation peut être ignoré lorsqu'elle renvoie un code de sortie particulier.
Si une étape de compilation échoue avec un code de sortie correspondant à la valeur que vous avez fournie dans allowExitCodes
, Cloud Build autorise cette étape de compilation à échouer sans que l'ensemble de la compilation échoue.
Si toutes les étapes de compilation échouent, mais que chaque étape se termine par un code que vous avez spécifié dans le champ allowExitCodes
, la compilation réussit quand même.
Toutefois, si l'étape de compilation échoue et qu'elle génère un autre code de sortie (qui ne correspond pas à la valeur que vous avez spécifiée dans allowExitCodes
), la compilation globale échouera.
Le ou les codes de sortie adaptés à votre build dépendent de votre logiciel. Exemple : "1" est un code de sortie
courant sous Linux. Vous pouvez également définir vos propres codes de sortie dans les scripts. Le champ allowExitCodes
accepte les nombres inférieurs ou égaux à 255.
Ce champ est prioritaire sur allowFailure
.
L'extrait de code suivant permet à la compilation de réussir lorsque la première étape échoue avec l'un des codes de sortie fournis :
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
Utilisez le champ timeout
d'une compilation pour spécifier la durée pendant laquelle son exécution doit être autorisée, à la seconde près. Si ce temps est écoulé, les travaux liés à cette compilation cessent et l'état de la compilation est défini sur TIMEOUT
. Si timeout
n'est pas défini, la valeur par défaut timeout
est de 60 minutes.
s'appliquent à la compilation. La valeur maximale pouvant être appliquée au champ timeout
est de 24 heures. La valeur timeout
doit être exprimé en secondes, comprendre un maximum de neuf chiffres décimaux et se terminer par "s". Exemple: 3.5s
Dans l'extrait de code suivant, timeout
est défini sur 660 secondes pour éviter que la compilation ne soit désactivée en raison de la mise en veille :
YAML
steps:
- name: 'ubuntu'
args: ['sleep', '600']
timeout: 660s
JSON
{
"steps": [
{
"name": "ubuntu",
"args": [
"sleep",
"600"
]
}
],
"timeout": "660s"
}
queueTtl
Utilisez le champ queueTtl
pour spécifier la durée pendant laquelle un build peut être mis en file d'attente. Si un build se trouve dans la file d'attente plus longtemps que la valeur définie dans queueTtl
, il expire et son état est défini sur EXPIRED
. Si aucune valeur n'est spécifiée, Cloud Build utilise la valeur par défaut de
3600s
(1 heure). queueTtl
prend effet à partir de createTime
. queueTtl
doit être exprimé en secondes, comprendre un maximum de neuf chiffres décimaux et se terminer par "s" (par exemple, 3.5s
).
Dans l'extrait de code suivant, timeout
est défini sur 20s
, et queueTtl
sur 10s
.
queueTtl
se lance à createTime
, ce qui correspond à l'heure à laquelle la compilation est demandée, et timeout
se lance à startTime
, ce qui correspond à l'heure à laquelle la compilation commence. Par conséquent, queueTtl
expire à createTime
+ 10s
, sauf si la compilation commence à ce moment-là.
YAML
steps:
- name: 'ubuntu'
args: ['sleep', '5']
timeout: 20s
queueTtl: 10s
JSON
{
"steps": [
{
"name": "ubuntu",
"args": [
"sleep",
"5"
]
}
],
"timeout": "20s",
"queueTtl": "10s"
}
logsBucket
Définissez le champ logsBucket
d'une compilation afin de spécifier un bucket Cloud Storage dans lequel écrire les journaux. Si vous ne définissez pas ce champ, Cloud Build utilise un bucket par défaut pour stocker les journaux de compilation.
L'extrait de code suivant définit un bucket de journaux pour stocker les journaux de compilation :
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
Utilisez le champ options
pour spécifier les arguments facultatifs suivants pour votre compilation :
env
: liste de définitions de variables d'environnement globales qui existent pour toutes les étapes de compilation associées à cette compilation. Si une variable est définie à la fois globalement et dans une étape de compilation, la variable utilise la valeur de l'étape de compilation. Les éléments sont au format KEY=VALUE
pour la variable d'environnement KEY
ayant la valeur VALUE
.
secretEnv
: liste de variables d'environnement globales chiffrées à l'aide d'une clé de chiffrement Cloud Key Management Service qui est disponible pour toutes les étapes de compilation associées à cette compilation.
Ces valeurs doivent être définies dans le champ Secret
de la compilation.
volumes
: liste des volumes à installer globalement pour TOUTES les étapes de compilation. Chaque volume est créé sous la forme d'un volume vide avant le début du processus de compilation. Une fois la compilation terminée, les volumes et leur contenu sont supprimés. Les noms et les chemins d'accès des volumes globaux ne peuvent pas entrer en conflit avec les volumes définis lors d'une étape de compilation. L'utilisation d'un volume global dans une compilation ne comportant qu'une seule étape n'est pas valide, car elle indique une requête de compilation avec une configuration incorrecte.
sourceProvenanceHash
: définissez l'option sourceProvenanceHash
pour spécifier l'algorithme de hachage pour la provenance de la source. L'extrait de code suivant indique que l'algorithme de hachage est 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 propose quatre types de machines virtuelles à haute capacité de processeur pour exécuter vos compilations: deux types de machines avec huit processeurs et deux types de machines avec 32 processeurs. Cloud Build fournit également deux types de machines virtuelles supplémentaires avec un ou deux processeurs pour exécuter vos compilations. Le type de machine par défaut est e2-standard-2
avec deux processeurs.
Le fait de demander une machine virtuelle à haute capacité de processeur peut augmenter le temps de démarrage de la compilation. Ajoutez l'option machineType
pour demander une machine virtuelle à capacité de calcul plus élevée :
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"
}
}
Pour plus d'informations sur l'utilisation de l'option machineType
, consultez la section Accélérer les compilations.
diskSizeGb
: utilisez l'option diskSizeGb
pour demander une taille de disque personnalisée pour votre compilation. La
que la taille maximale que vous pouvez
demander est de 4 000 Go.
L'extrait de code suivant demande une taille de disque de 200 Go :
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
: utilisez cette option pour insérer des journaux de compilation en flux continu sur Cloud Storage. Par défaut, Cloud Build collecte les journaux de compilation une fois la compilation terminée. Cette option indique si vous souhaitez insérer des journaux de compilation en flux continu en temps réel via le processus de compilation. L'extrait de code suivant indique que les journaux de compilation sont insérés en flux continu sur 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
: utilisez cette option pour indiquer si vous souhaitez stocker les journaux dans Cloud Logging ou Cloud Storage. Si vous ne définissez pas cette option, Cloud Build stocke les journaux à la fois dans Cloud Logging et Cloud Storage. Vous pouvez définir l'option logging
sur GCS_ONLY
pour stocker les journaux uniquement dans Cloud Storage. L'extrait de code suivant indique que les journaux sont stockés dans 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'option defaultLogsBucketBehavior
vous permet de configurer Cloud Build pour créer un bucket de journaux par défaut au sein de votre propre projet, dans la même région que votre compilation. Pour en savoir plus, consultez la section Stocker les journaux de compilation dans un bucket régionalisé et appartenant à l'utilisateur.
La configuration de compilation suivante définit le champ defaultLogsBucketBehavior
sur la valeur 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
: utilisez cette option pour activer ou désactiver explicitement l'expansion des paramètres bash dans les substitutions. Si votre compilation est appelée par un déclencheur, le champ dynamicSubstitutions
est toujours défini sur "true" et n'a pas besoin d'être spécifié dans le fichier de configuration de compilation. Si votre compilation est appelée manuellement, vous devez définir le champ dynamicSubstitutions
sur "true" pour que les extensions de paramètre bash soient interprétées lors de l'exécution de la compilation.
automapSubstitutions
:
Mappez automatiquement toutes les substitutions avec les variables d'environnement qui seront
disponibles tout au long du build. Pour en savoir plus, consultez la section Remplacer les valeurs des variables.
substitutionOption
: définissez cette option et le champ substitutions
ci-dessous pour spécifier le comportement en cas d'erreur au cours des contrôles de substitution.
pool
: définissez la valeur de ce champ sur le nom de ressource du pool privé pour exécuter la compilation. Pour savoir comment exécuter une compilation sur un pool privé, consultez la section Exécuter des compilations dans un pool privé.
requestedVerifyOption
: définissez la valeur de requestedVerifyOption
sur VERIFIED
pour activer et vérifier la génération d'attestations et de métadonnées de provenance pour votre build. Une fois ces paramètres définis, vos builds ne seront marqués que SUCCESS
si des attestations et une provenance sont générées.
substitutions
Utilisez des substitutions dans le fichier de configuration de compilation pour remplacer des variables spécifiques au moment de la compilation. Les substitutions sont utiles pour les variables dont la valeur n'est pas connue avant la compilation, ou pour réutiliser une requête de compilation existante avec différentes valeurs de variables. Par défaut, la compilation renvoie une erreur si une variable de substitution ou une substitution est manquante. Toutefois, vous pouvez utiliser l'option ALLOW_LOOSE
pour ignorer cette vérification.
L'extrait de code suivant utilise des substitutions pour imprimer "hello world.". L'option de substitution ALLOW_LOOSE
est définie, ce qui signifie que la compilation ne renverra pas d'erreur en cas de variable de substitution ou de substitution manquante.
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"
}
}
Pour plus d'informations sur l'utilisation de substitutions
, consultez la section Remplacer les valeurs des variables.
tags
Utilisez le champ tags
pour regrouper les compilations et pour filtrer les compilations. La configuration suivante définit deux tags nommés mytag1
et 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
Utilisez ce champ pour utiliser un secret Secret Manager avec Cloud Build. Pour en savoir plus, consultez la page Utiliser des secrets.
secrets
Le champ secrets permet d'associer des variables d'environnement de code secret contenant des valeurs chiffrées à la clé Cloud KMS à utiliser pour déchiffrer la valeur.
serviceAccount
Utilisez ce champ pour spécifier le compte de service IAM à utiliser au moment de la compilation. Pour en savoir plus, consultez la section Configurer des comptes de service spécifiés par l'utilisateur.
images
Le champ images
du fichier de configuration de compilation spécifie un ou plusieurs fichiers Docker Linux
images à transférer par Cloud Build vers Artifact Registry ou Container Registry
(obsolète). Une compilation peut effectuer des tâches sans produire d'images Linux Docker. Cependant, si vous compilez des images et ne les envoyez pas vers le registre, elles sont supprimées au terme de la compilation. Si aucune image spécifiée n'est produite lors de la compilation, celle-ci échoue. Pour plus
des informations sur le stockage d'images, consultez
Stockez les artefacts dans Artifact Registry.
La configuration de compilation suivante définit le champ images
pour stocker l'image compilée :
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
Le champ artifacts
du fichier de configuration de compilation spécifie un ou plusieurs artefacts non issus de conteneurs à stocker dans Cloud Storage. Pour en savoir plus sur
sur le stockage d'artefacts non issus de conteneurs, consultez Stocker des artefacts de compilation dans Cloud Storage.
La configuration de compilation suivante définit le champ artifacts
pour stocker le package Go compilé dans 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
Le champ mavenArtifacts
vous permet d'importer des artefacts Java sans conteneur dans des dépôts Maven dans Artifact Registry. Pour en savoir plus, consultez la page Créer et tester des applications Java.
La configuration de compilation suivante définit le champ mavenArtifacts
pour importer le fichier empaqueté my-app-1.0-SNAPSHOT.jar
dans le dépôt 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
Le champ pythonPackages
vous permet d'importer des packages Python dans Artifact Registry. Pour en savoir plus, consultez Créer et tester des applications Python.
La configuration de compilation suivante définit le champ pythonPackages
pour importer le package Python dist/my-pkg.whl
dans le dépôt 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
Utilisez le champ npmPackages
pour configurer Cloud Build afin d'importer votre
créé des packages npm sur les
dépôts compatibles dans Artifact Registry. Vous devez
fournissez des valeurs pour repository
et packagePath
.
Le champ repository
spécifie le dépôt Artifact Registry dans lequel stocker vos packages. Le champ packagePath
spécifie le répertoire local contenant le package npm à importer. Ce répertoire doit contenir un fichier package.json
.
Nous vous recommandons d'utiliser un chemin absolu pour la valeur de packagePath
. Vous pouvez utiliser
.
pour faire référence au répertoire de travail actuel, mais le champ ne peut pas être omis
ou laissés vides. Pour en savoir plus sur l'utilisation de npmPackages
, consultez Créer et tester des applications Node.js.
La configuration de compilation suivante définit le champ npmPackages
pour importer le npm
package du répertoire /workspace/my-pkg
vers le dépôt 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"
}
]
}
}
Utiliser des fichiers Dockerfile
Si vous exécutez des compilations Docker dans Cloud Build à l'aide de la commande
gcloud CLI ou build trigger, vous pouvez utiliser un Dockerfile
sans fichier de configuration de compilation distinct. Si vous souhaitez apporter des modifications supplémentaires à vos compilations Docker, vous pouvez fournir un fichier de configuration de compilation en plus du Dockerfile
. Pour savoir comment créer une image Docker à l'aide d'un fichier Dockerfile
, consultez la section Démarrage rapide: compilation.
Réseau Cloud Build
Lorsque Cloud Build exécute une étape de compilation, il associe automatiquement le conteneur de l'étape à un réseau Docker local nommé cloudbuild
. Le réseau cloudbuild
héberge les Identifiants par défaut de l'application (ADC) que les services Google Cloud peuvent utiliser afin de rechercher automatiquement vos identifiants. Si vous exécutez des conteneurs Docker imbriqués et que vous souhaitez exposer les identifiants par défaut de l'application à un conteneur sous-jacent ou utiliser gcloud
dans une étape docker
, utilisez l'option --network
dans votre étape 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",
"."
]
}
]
}
Étape suivante
- Découvrez comment créer un fichier de configuration de compilation pour configurer des compilations pour Cloud Build.
- Lisez la section Démarrer une compilation manuellement pour découvrir comment exécuter des compilations dans Cloud Build.