Créer un schéma de fichier de configuration

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.

Remarque : Si vous utilisez les IDE IntelliJ ou VS Code, vous pouvez utiliser Cloud Code pour créer vos fichiers de configuration YAML. Cloud Code est intégré à l'éditeur Cloud Shell et ne nécessite aucune configuration. Pour plus d'informations, consultez les pages Cloud Code pour VS Code et Cloud Code pour IntelliJ.

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"
        ]
    }
    ]
}

Remarque : Le champ "timeout" relatif au délai d'expiration existe à la fois pour l'étape de compilation et pour la compilation : le champ timeout d'une étape de compilation définit la durée d'exécution autorisée pour l'étape et le champ timeout d'une compilation indique la durée d'exécution autorisée pour la compilation.

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"
}

Remarque : Le champ "timeout" relatif au délai d'expiration existe à la fois pour l'étape de compilation et pour la compilation : le champ timeout d'une étape de compilation définit la durée d'exécution autorisée pour l'étape et le champ timeout d'une compilation indique la durée d'exécution autorisée pour la compilation.

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"
    }
}

Remarque : Si votre compilation est appelée par un déclencheur, l'option ALLOW_LOOSE est définie par défaut. Dans ce cas, votre compilation ne renverra pas d'erreur s'il manque une variable de substitution ou une substitution. Vous ne pouvez pas remplacer l'option ALLOW_LOOSE pour les compilations appelées par des déclencheurs.

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.

Remarque :Utilisez availableSecrets au lieu de secrets. Pour en savoir plus, consultez les pages Utiliser des secrets et Utiliser des identifiants chiffrés.

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.