Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Modifier les paramètres du projet de construction dans AWS CodeBuild Vous pouvez utiliser la AWS CodeBuild console ou AWS SDKs pour modifier les paramètres d'un projet de construction. AWS CLI Si vous ajoutez des rapports de test à un projet de génération, assurez-vous que votre rôle IAM dispose des autorisations décrites dans[Autorisations relatives aux rapports de test](test-permissions.md). **Topics** + [Modification des paramètres d'un projet de génération (console)](#change-project-console) + [Modification des paramètres d'un projet de génération (AWS CLI)](#change-project-cli) + [Modification des paramètres d'un projet de génération (AWS SDKs)](#change-project-sdks) ## Modification des paramètres d'un projet de génération (console) Pour modifier les paramètres d'un projet de génération, effectuez la procédure suivante : 1. Ouvrez la AWS CodeBuild console sur [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home). 1. Dans le volet de navigation, choisissez **Projets de génération**. 1. Effectuez l’une des actions suivantes : + Cliquez sur le lien du projet de génération à modifier, puis choisissez **Détails de génération**. + Cliquez sur le bouton en regard du projet de génération à modifier, choisissez **View details (Afficher les détails)**, puis **Détails de génération**. Vous pouvez modifier les sections suivantes : **Topics** + [Configuration du projet](#change-project-console-project-config) + [Source](#change-project-console-source) + [Environnement](#change-project-console-environment) + [Spécifications de construction](#change-project-console-buildspec) + [Configuration par lots](#change-project-console-batch-config) + [Artefacts](#change-project-console-artifacts) + [Journaux](#change-project-console-logs) ### Configuration du projet Dans la section **Configuration du projet**, choisissez **Modifier**. Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Vous pouvez modifier les propriétés suivantes. **Description** Entrez une description facultative du projet de construction pour aider les autres utilisateurs à comprendre à quoi sert ce projet. **Construire un badge** Sélectionnez **Enable build badge (Activer le badge de génération)** pour rendre le statut de génération de votre projet visible et intégrable. Pour de plus amples informations, veuillez consulter [Exemple de badges de génération](sample-build-badges.md). Le badge de construction ne s'applique pas si votre fournisseur source est Amazon S3. **Activer la limite de génération simultanée** Si vous souhaitez limiter le nombre de builds simultanés pour ce projet, effectuez les opérations suivantes : 1. Sélectionnez **Restreindre le nombre de versions simultanées que ce projet peut démarrer**. 1. Dans **Limite de génération simultanée**, entrez le nombre maximum de versions simultanées autorisées pour ce projet. Cette limite ne peut pas être supérieure à la limite de création simultanée définie pour le compte. Si vous essayez de saisir un nombre supérieur à la limite du compte, un message d'erreur s'affiche. Les nouvelles générations ne sont démarrées que si le nombre actuel de générations est inférieur ou égal à cette limite. Si le nombre actuel de générations atteint cette limite, les nouvelles générations sont limitées et ne sont pas exécutées. **Permettre l'accès public aux builds** Pour que les résultats de génération de votre projet soient accessibles au public, y compris aux utilisateurs n'ayant pas accès à un AWS compte, sélectionnez **Activer l'accès public** aux versions et confirmez que vous souhaitez rendre les résultats de génération publics. Les propriétés suivantes sont utilisées pour les projets de construction publics : **Rôle du service public de construction** Sélectionnez **Nouveau rôle de service** si vous souhaitez CodeBuild créer un nouveau rôle de service pour vous, ou **Rôle de service existant** si vous souhaitez utiliser un rôle de service existant. Le rôle de service de construction public CodeBuild permet de lire les CloudWatch journaux et de télécharger les artefacts Amazon S3 pour les versions du projet. Cela est nécessaire pour mettre les journaux de construction et les artefacts du projet à la disposition du public. **Rôle de service** Entrez le nom du nouveau rôle de service ou d'un rôle de service existant. Pour que les résultats de compilation de votre projet soient privés, décochez **Activer l'accès public aux builds**. Pour de plus amples informations, veuillez consulter [Obtenir un projet de construction public URLs](public-builds.md). Les points suivants doivent être pris en compte lorsque vous publiez les résultats de construction de votre projet : + Tous les résultats de construction, les journaux et les artefacts d'un projet, y compris les versions exécutées lorsque le projet était privé, sont accessibles au public. + Tous les journaux de construction et les artefacts sont accessibles au public. Les variables d'environnement, le code source et d'autres informations sensibles peuvent avoir été générés dans les journaux de construction et les artefacts. Vous devez faire attention aux informations qui sont affichées dans les journaux de construction. Voici certaines des meilleures pratiques : + Ne stockez pas de valeurs sensibles, en particulier les identifiants de clé AWS d'accès et les clés d'accès secrètes, dans les variables d'environnement. Nous vous recommandons d'utiliser un magasin de paramètres Amazon EC2 Systems Manager AWS Secrets Manager ou de stocker des valeurs sensibles. + Suivez cette [Bonnes pratiques d'utilisation des webhooks](webhooks.md#webhook-best-practices) procédure pour limiter les entités qui peuvent déclencher une construction, et ne stockez pas la spécification de construction dans le projet lui-même, afin de garantir que vos webhooks sont aussi sécurisés que possible. + Un utilisateur malveillant peut utiliser des versions publiques pour distribuer des artefacts malveillants. Nous recommandons aux administrateurs de projet de passer en revue toutes les pull requests afin de vérifier qu'il s'agit d'une modification légitime. Nous vous recommandons également de valider tous les artefacts à l'aide de leurs checksums afin de vous assurer que les bons artefacts sont téléchargés. **Informations supplémentaires** Pour les **balises**, entrez le nom et la valeur de toutes les balises que vous souhaitez que les AWS services d'assistance utilisent. Utilisez **Ajouter une ligne** pour ajouter une balise. Vous pouvez ajouter jusqu’à 50 balises. ### Source Dans la section **Source**, choisissez **Modifier**. Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Vous pouvez modifier les propriétés suivantes : **Fournisseur de source** Choisissez le type de fournisseur de code source. Utilisez les listes suivantes pour effectuer des sélections adaptées à votre fournisseur de source : CodeBuild ne prend pas en charge Bitbucket Server. ------ #### [ Amazon S3 ] **Compartiment** Choisissez le nom du compartiment d'entrée contenant le code source. **Clé d'objet S3 ou dossier S3** Entrez le nom du fichier ZIP ou le chemin d'accès au dossier contenant le code source. Entrez une barre oblique (/) pour tout télécharger dans le compartiment S3. **Version de la source** Entrez l'ID de version de l'objet qui représente la version de votre fichier d'entrée. Pour plus d'informations, consultez[Exemple de version source avec AWS CodeBuild](sample-source-version.md). ------ #### [ CodeCommit ] **Référentiel** Choisissez le référentiel que vous souhaitez utiliser. **Type de référence** Choisissez **Branch**, **Git tag** ou **Commit ID** pour spécifier la version de votre code source. Pour de plus amples informations, veuillez consulter [Exemple de version source avec AWS CodeBuild](sample-source-version.md). Nous vous recommandons de choisir des noms de branche Git qui ne ressemblent pas à des validations IDs, tels que `811dd1ba1aba14473856cee38308caed7190c0d` ou`5392f7`. Cela vous permet d'éviter les collisions entre Git Checkout et les validations réelles. **Profondeur du clone Git** Choisissez de créer un clone superficiel avec un historique tronqué au nombre de validations spécifié. Si vous souhaitez un clone complet, choisissez **Full**. **Sous-modules Git** Sélectionnez **Use Git submodules (Utiliser les sous-modules Git)** si vous souhaitez inclure les sous-modules Git dans votre référentiel. ------ #### [ Bitbucket ] **Accréditation** Choisissez **Informations d'identification source par défaut** ou Informations **d'identification source personnalisées** et suivez les instructions pour gérer les informations d'identification source par défaut ou personnaliser les informations d'identification source. **Type de connexion** Choisissez **CodeConnections**le **OAuth**mot de **passe de l'application** ou le **jeton d'accès personnel** auquel vous souhaitez vous connecter CodeBuild. **Connection** Sélectionnez une connexion Bitbucket ou un secret de Secrets Manager pour vous connecter via le type de connexion que vous avez spécifié. **Référentiel** Choisissez **Repository dans mon compte Bitbucket** ou **Public repository** et saisissez l'URL du référentiel. **Version de la source** Entrez une branche, un ID de validation, une balise ou une référence et un ID de validation. Pour de plus amples informations, consultez [Exemple de version source avec AWS CodeBuild](sample-source-version.md). Nous vous recommandons de choisir des noms de branche Git qui ne ressemblent pas à des validations IDs, tels que `811dd1ba1aba14473856cee38308caed7190c0d` ou`5392f7`. Cela vous permet d'éviter les collisions entre Git Checkout et les validations réelles. **Profondeur du clone Git** Choisissez **Git clone depth (Profondeur du clone Git)** pour créer un clone superficiel avec un historique tronqué au nombre de validations spécifié. Si vous souhaitez un clone complet, choisissez **Full**. **Sous-modules Git** Sélectionnez **Use Git submodules (Utiliser les sous-modules Git)** si vous souhaitez inclure les sous-modules Git dans votre référentiel. **Statut de la génération** Sélectionnez **Signaler les statuts de construction au fournisseur source au début et à la fin de vos builds** si vous souhaitez que l'état du début et de la fin de votre build soit signalé à votre fournisseur source. Pour pouvoir signaler l'état de construction au fournisseur de source, l'utilisateur associé au fournisseur de source doit avoir un accès en écriture au dépôt. Si l'utilisateur ne dispose pas d'un accès en écriture, l'état de construction ne peut pas être mis à jour. Pour de plus amples informations, veuillez consulter [Accès au fournisseur de source](access-tokens.md). Pour **le contexte de statut**, entrez la valeur à utiliser pour le `name` paramètre dans le statut de validation de Bitbucket. Pour plus d'informations, voir [build](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build) dans la documentation de l'API Bitbucket. Pour **l'URL cible**, entrez la valeur à utiliser pour le `url` paramètre dans le statut de validation de Bitbucket. Pour plus d'informations, voir [build](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build) dans la documentation de l'API Bitbucket. L'état d'une compilation déclenchée par un webhook est toujours communiqué au fournisseur source. Pour que le statut d'une version démarrée depuis la console ou un appel d'API soit signalé au fournisseur source, vous devez sélectionner ce paramètre. Si les builds de votre projet sont déclenchés par un webhook, vous devez envoyer un nouveau commit au dépôt pour que la modification de ce paramètre prenne effet. Dans **Événements de webhook source primaire**, sélectionnez **Reconstruire chaque fois qu'une modification de code est envoyée à ce référentiel** si vous CodeBuild souhaitez générer le code source chaque fois qu'une modification de code est transférée vers ce référentiel. Pour plus d'informations sur les webhooks et les groupes de filtres, consultez[Événements du webhook Bitbucket](bitbucket-webhook.md). ------ #### [ GitHub ] **Accréditation** Choisissez **Informations d'identification source par défaut** ou Informations **d'identification source personnalisées** et suivez les instructions pour gérer les informations d'identification source par défaut ou personnaliser les informations d'identification source. **Type de connexion** Choisissez **GitHub Application** ou **jeton d'accès personnel** auquel vous souhaitez vous connecter CodeBuild. **OAuth** **Connection** Sélectionnez une GitHub connexion ou un secret du Gestionnaire de Secrets pour vous connecter via le type de connexion que vous avez spécifié. **Référentiel** Choisissez **Repository in my GitHub account**, **Public repository** ou **GitHub Scoped Webhook** et entrez l'URL du référentiel. **Version de la source** Entrez une branche, un ID de validation, une balise ou une référence et un ID de validation. Pour de plus amples informations, consultez [Exemple de version source avec AWS CodeBuild](sample-source-version.md). Nous vous recommandons de choisir des noms de branche Git qui ne ressemblent pas à des validations IDs, tels que `811dd1ba1aba14473856cee38308caed7190c0d` ou`5392f7`. Cela vous permet d'éviter les collisions entre Git Checkout et les validations réelles. **Profondeur du clone Git** Choisissez **Git clone depth (Profondeur du clone Git)** pour créer un clone superficiel avec un historique tronqué au nombre de validations spécifié. Si vous souhaitez un clone complet, choisissez **Full**. **Sous-modules Git** Sélectionnez **Use Git submodules (Utiliser les sous-modules Git)** si vous souhaitez inclure les sous-modules Git dans votre référentiel. **Statut de la génération** Sélectionnez **Signaler les statuts de construction au fournisseur source au début et à la fin de vos builds** si vous souhaitez que l'état du début et de la fin de votre build soit signalé à votre fournisseur source. Pour pouvoir signaler l'état de construction au fournisseur de source, l'utilisateur associé au fournisseur de source doit avoir un accès en écriture au dépôt. Si l'utilisateur ne dispose pas d'un accès en écriture, l'état de construction ne peut pas être mis à jour. Pour de plus amples informations, veuillez consulter [Accès au fournisseur de source](access-tokens.md). Pour **le contexte de statut**, entrez la valeur à utiliser pour le `context` paramètre dans le statut de GitHub validation. Pour plus d'informations, consultez la section [Créer un statut de validation](https://developer.github.com/v3/repos/statuses/#create-a-commit-status) dans le guide du GitHub développeur. Pour **URL cible**, entrez la valeur à utiliser pour le `target_url` paramètre dans le statut de GitHub validation. Pour plus d'informations, consultez la section [Créer un statut de validation](https://developer.github.com/v3/repos/statuses/#create-a-commit-status) dans le guide du GitHub développeur. L'état d'une compilation déclenchée par un webhook est toujours communiqué au fournisseur source. Pour que le statut d'une version démarrée depuis la console ou un appel d'API soit signalé au fournisseur source, vous devez sélectionner ce paramètre. Si les builds de votre projet sont déclenchés par un webhook, vous devez envoyer un nouveau commit au dépôt pour que la modification de ce paramètre prenne effet. Dans **Événements de webhook source primaire**, sélectionnez **Reconstruire chaque fois qu'une modification de code est envoyée à ce référentiel** si vous CodeBuild souhaitez générer le code source chaque fois qu'une modification de code est transférée vers ce référentiel. Pour plus d'informations sur les webhooks et les groupes de filtres, consultez[GitHub événements webhook](github-webhook.md). ------ #### [ GitHub Enterprise Server ] **Accréditation** Choisissez **Informations d'identification source par défaut** ou Informations **d'identification source personnalisées** et suivez les instructions pour gérer les informations d'identification source par défaut ou personnaliser les informations d'identification source. **Type de connexion** Choisissez **CodeConnections**un **jeton d'accès personnel** auquel vous souhaitez vous connecter CodeBuild. **Connection** Sélectionnez une connexion GitHub Enterprise ou un secret Secrets Manager pour vous connecter via le type de connexion que vous avez spécifié. **Référentiel** Choisissez **Repository in my GitHub Enterprise account** ou **GitHub Enterprise Scoped Webhook** et entrez l'URL du référentiel. **Version de la source** Entrez une pull request, une branche, un identifiant de validation, une balise ou une référence et un identifiant de validation. Pour de plus amples informations, veuillez consulter [Exemple de version source avec AWS CodeBuild](sample-source-version.md). Nous vous recommandons de choisir des noms de branche Git qui ne ressemblent pas à des validations IDs, tels que `811dd1ba1aba14473856cee38308caed7190c0d` ou`5392f7`. Cela vous permet d'éviter les collisions entre Git Checkout et les validations réelles. **Profondeur du clone Git** Choisissez **Git clone depth (Profondeur du clone Git)** pour créer un clone superficiel avec un historique tronqué au nombre de validations spécifié. Si vous souhaitez un clone complet, choisissez **Full**. **Sous-modules Git** Sélectionnez **Use Git submodules (Utiliser les sous-modules Git)** si vous souhaitez inclure les sous-modules Git dans votre référentiel. **Statut de la génération** Sélectionnez **Signaler les statuts de construction au fournisseur source au début et à la fin de vos builds** si vous souhaitez que l'état du début et de la fin de votre build soit signalé à votre fournisseur source. Pour pouvoir signaler l'état de construction au fournisseur de source, l'utilisateur associé au fournisseur de source doit avoir un accès en écriture au dépôt. Si l'utilisateur ne dispose pas d'un accès en écriture, l'état de construction ne peut pas être mis à jour. Pour de plus amples informations, veuillez consulter [Accès au fournisseur de source](access-tokens.md). Pour **le contexte de statut**, entrez la valeur à utiliser pour le `context` paramètre dans le statut de GitHub validation. Pour plus d'informations, consultez la section [Créer un statut de validation](https://developer.github.com/v3/repos/statuses/#create-a-commit-status) dans le guide du GitHub développeur. Pour **URL cible**, entrez la valeur à utiliser pour le `target_url` paramètre dans le statut de GitHub validation. Pour plus d'informations, consultez la section [Créer un statut de validation](https://developer.github.com/v3/repos/statuses/#create-a-commit-status) dans le guide du GitHub développeur. L'état d'une compilation déclenchée par un webhook est toujours communiqué au fournisseur source. Pour que le statut d'une version démarrée depuis la console ou un appel d'API soit signalé au fournisseur source, vous devez sélectionner ce paramètre. Si les builds de votre projet sont déclenchés par un webhook, vous devez envoyer un nouveau commit au dépôt pour que la modification de ce paramètre prenne effet. **SSL non sécurisé** Sélectionnez **Activer le protocole SSL non sécurisé** pour ignorer les avertissements SSL lors de la connexion au référentiel de votre projet GitHub d'entreprise. Dans **Événements de webhook source primaire**, sélectionnez **Reconstruire chaque fois qu'une modification de code est envoyée à ce référentiel** si vous CodeBuild souhaitez générer le code source chaque fois qu'une modification de code est transférée vers ce référentiel. Pour plus d'informations sur les webhooks et les groupes de filtres, consultez[GitHub événements webhook](github-webhook.md). ------ #### [ GitLab ] **Accréditation** Choisissez **Informations d'identification source par défaut** ou Informations **d'identification source personnalisées** et suivez les instructions pour gérer les informations d'identification source par défaut ou personnaliser les informations d'identification source. **Type de connexion** **CodeConnections**est utilisé pour se connecter GitLab à CodeBuild. **Connection** Sélectionnez une GitLab connexion par laquelle vous souhaitez vous connecter CodeConnections. **Référentiel** Choisissez le référentiel que vous souhaitez utiliser. **Version de la source** Entrez un identifiant de pull request, une branche, un identifiant de validation, une balise ou une référence et un identifiant de validation. Pour de plus amples informations, veuillez consulter [Exemple de version source avec AWS CodeBuild](sample-source-version.md). Nous vous recommandons de choisir des noms de branche Git qui ne ressemblent pas à des validations IDs, tels que `811dd1ba1aba14473856cee38308caed7190c0d` ou`5392f7`. Cela vous permet d'éviter les collisions entre Git Checkout et les validations réelles. **Profondeur du clone Git** Choisissez **Git clone depth (Profondeur du clone Git)** pour créer un clone superficiel avec un historique tronqué au nombre de validations spécifié. Si vous souhaitez un clone complet, choisissez **Full**. **Statut de la génération** Sélectionnez **Signaler les statuts de construction au fournisseur source au début et à la fin de vos builds** si vous souhaitez que l'état du début et de la fin de votre build soit signalé à votre fournisseur source. Pour pouvoir signaler l'état de construction au fournisseur de source, l'utilisateur associé au fournisseur de source doit avoir un accès en écriture au dépôt. Si l'utilisateur ne dispose pas d'un accès en écriture, l'état de construction ne peut pas être mis à jour. Pour de plus amples informations, veuillez consulter [Accès au fournisseur de source](access-tokens.md). ------ #### [ GitLab Self Managed ] **Accréditation** Choisissez **Informations d'identification source par défaut** ou Informations **d'identification source personnalisées** et suivez les instructions pour gérer les informations d'identification source par défaut ou personnaliser les informations d'identification source. **Type de connexion** **CodeConnections**est utilisé pour connecter GitLab Self Managed à CodeBuild. **Connection** Sélectionnez une connexion GitLab autogérée par laquelle vous souhaitez vous connecter CodeConnections. **Référentiel** Choisissez le référentiel que vous souhaitez utiliser. **Version de la source** Entrez un identifiant de pull request, une branche, un identifiant de validation, une balise ou une référence et un identifiant de validation. Pour de plus amples informations, veuillez consulter [Exemple de version source avec AWS CodeBuild](sample-source-version.md). Nous vous recommandons de choisir des noms de branche Git qui ne ressemblent pas à des validations IDs, tels que `811dd1ba1aba14473856cee38308caed7190c0d` ou`5392f7`. Cela vous permet d'éviter les collisions entre Git Checkout et les validations réelles. **Profondeur du clone Git** Choisissez **Git clone depth (Profondeur du clone Git)** pour créer un clone superficiel avec un historique tronqué au nombre de validations spécifié. Si vous souhaitez un clone complet, choisissez **Full**. **Statut de la génération** Sélectionnez **Signaler les statuts de construction au fournisseur source au début et à la fin de vos builds** si vous souhaitez que l'état du début et de la fin de votre build soit signalé à votre fournisseur source. Pour pouvoir signaler l'état de construction au fournisseur de source, l'utilisateur associé au fournisseur de source doit avoir un accès en écriture au dépôt. Si l'utilisateur ne dispose pas d'un accès en écriture, l'état de construction ne peut pas être mis à jour. Pour de plus amples informations, veuillez consulter [Accès au fournisseur de source](access-tokens.md). ------ ### Environnement Dans la section **Environnement**, choisissez **Modifier**. Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Vous pouvez modifier les propriétés suivantes : **Modèle de provisionnement** Pour modifier le modèle de provisionnement, choisissez **Modifier le modèle de provisionnement** et effectuez l'une des opérations suivantes : + Pour utiliser des flottes à la demande gérées par AWS CodeBuild, choisissez **On-Demand**. Avec des flottes à la demande, CodeBuild fournit le calcul nécessaire à vos builds. Les machines sont détruites à la fin de la construction. Les flottes à la demande sont entièrement gérées et incluent des fonctionnalités de mise à l'échelle automatique pour faire face aux pics de demande. + Pour utiliser des flottes de capacité réservée gérées par AWS CodeBuild, choisissez **Capacité réservée**, puis sélectionnez un **nom de flotte**. Avec les flottes de capacité réservée, vous configurez un ensemble d'instances dédiées pour votre environnement de construction. Ces machines restent inactives, prêtes à traiter les builds ou les tests immédiatement et réduisent les durées de construction. Avec des flottes de capacité réservées, vos machines fonctionnent en permanence et continueront d'entraîner des coûts tant qu'elles seront approvisionnées. Pour plus d'informations, consultez [Exécutez des builds sur des flottes à capacité réservée](fleets.md). **Image de l'environnement** Pour modifier l'image de construction, choisissez **Remplacer l'image** et effectuez l'une des opérations suivantes : + Pour utiliser une image Docker gérée par AWS CodeBuild, choisissez **Image gérée**, puis sélectionnez **Système d'exploitation**, **Runtime (s)**, **Image** et **Version de l'image**. Effectuez votre sélection pour **Type d'environnement** si cette option est disponible. + Pour utiliser une autre image Docker, choisissez **Image personnalisée**. Pour le **type d'environnement**, choisissez **ARM**, **Linux****, Linux GPU** ou **Windows**. Si vous choisissez **Other registry (Autre registre)**, pour **External registry URL (URL du registre externe)**, entrez le nom et la balise de l'image Docker dans Docker Hub au format `docker repository/docker image name`. Si vous choisissez **Amazon ECR**, utilisez le **référentiel Amazon ECR** et l'image **Amazon ECR pour choisir l'image** Docker dans votre compte. AWS + Pour utiliser une image Docker privée, choisissez **Image personnalisée**. Pour le **type d'environnement**, choisissez **ARM**, **Linux****, Linux GPU** ou **Windows**. Pour **Image registry (Registre de l'image)**, choisissez **Other registry (Autre registre)** et entrez l'ARN des informations d'identification de votre image Docker privée. Les informations d'identification doivent être créées par Secrets Manager. Pour plus d'informations, consultez [Présentation de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) dans le *Guide de l'utilisateur AWS Secrets Manager *. CodeBuild remplace le `ENTRYPOINT` pour les images Docker personnalisées. **Rôle de service** Effectuez l’une des actions suivantes : + Si vous n'avez pas de rôle CodeBuild de service, choisissez **Nouveau rôle de service**. Dans **Role name**, entrez un nom pour le nouveau rôle. + Si vous avez un rôle CodeBuild de service, choisissez **Rôle de service existant**. Dans **Role ARN**, choisissez le rôle de service. Lorsque vous utilisez la console pour créer un projet de génération, vous pouvez créer un rôle de CodeBuild service en même temps. Par défaut, le rôle fonctionne avec ce projet de génération uniquement. Si vous utilisez la console pour associer ce rôle de service à un autre projet de génération, le rôle est mis à jour pour fonctionner avec l'autre projet de génération. Un rôle de service peut fonctionner avec 10 projets de génération maximum. **Configuration supplémentaire** **Expiration** Spécifiez une valeur, comprise entre 5 minutes et 36 heures, après quoi la CodeBuild génération s'arrête si elle n'est pas terminée. Si les valeurs de **heures** et **minutes** sont laissées vides, la valeur par défaut de 60 minutes est utilisée. **privilégié** Sélectionnez **Activer cet indicateur si vous souhaitez créer des images Docker ou si vous souhaitez que vos versions bénéficient de privilèges élevés**. uniquement si vous prévoyez d'utiliser ce projet de génération pour créer des images Docker. Sinon, toutes les générations associées qui tentent d'interagir avec le démon Docker échouent. Vous devez également démarrer le démon Docker afin que vos générations puissent interagir avec celui-ci. Pour cela, vous pouvez initialiser le démon Docker au cours de la phase `install` de votre spécification de génération en exécutant les commandes de génération ci-après. N'exécutez pas ces commandes si vous avez choisi une image d'environnement de construction fournie CodeBuild par le support Docker. Par défaut, le démon Docker est activé pour les versions non VPC. Si vous souhaitez utiliser des conteneurs Docker pour les builds VPC, [consultez Runtime Privilege et Linux](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) Capabilities sur le site Web de Docker Docs et activez le mode privilégié. De plus, Windows ne prend pas en charge le mode privilégié. ``` - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 & - timeout 15 sh -c "until docker info; do echo .; sleep 1; done" ``` **VPC** Si vous souhaitez CodeBuild travailler avec votre VPC : + Pour le **VPC**, choisissez l'ID du VPC qui utilise. CodeBuild + Pour les sous-réseaux **VPC, choisissez les sous-réseaux** qui incluent les ressources qui utilisent. CodeBuild + Pour les **groupes de sécurité VPC**, choisissez les groupes de sécurité CodeBuild utilisés pour autoriser l'accès aux ressources du. VPCs Pour de plus amples informations, veuillez consulter [Utilisation AWS CodeBuild avec Amazon Virtual Private Cloud](vpc-support.md). **Calcul** Choisissez l'une des options disponibles. **Informations d'identification du registre** Spécifiez un identifiant de registre lorsque le projet est configuré avec une image de registre non privée. Ces informations d'identification ne seront utilisées que si les images sont remplacées par celles provenant de registres privés. **Variables d'environnement** Entrez le nom et la valeur, puis choisissez le type de chaque variable d'environnement à utiliser pour les builds. CodeBuild définit automatiquement la variable d'environnement pour votre AWS région. Vous devez définir les variables d'environnement suivantes si vous ne les avez pas ajoutées dans votre fichier buildspec.yml : + AWS\$1ACCOUNT\$1ID + IMAGE\$1REPO\$1NAME + IMAGE\$1TAG La console et AWS CLI les utilisateurs peuvent voir les variables d'environnement. Si la visibilité de vos variables d'environnement ne vous pose pas de problème, définissez les zones **Nom** et **Valeur**, puis définissez **Type** sur **Texte brut**. Nous vous recommandons de stocker une variable d'environnement avec une valeur sensible, telle qu'un identifiant de clé d' AWS accès, une clé d'accès AWS secrète ou un mot de passe en tant que paramètre dans Amazon EC2 Systems Manager Parameter Store AWS Secrets Manager ou. **Si vous utilisez Amazon EC2 Systems Manager Parameter Store, **choisissez** Parameter dans Type.** Dans **Nom**, entrez un identifiant CodeBuild à référencer. Pour **Value**, entrez le nom du paramètre tel qu'il est stocké dans le magasin de paramètres Amazon EC2 Systems Manager. Si l'on prend comme exemple un paramètre nommé `/CodeBuild/dockerLoginPassword`, pour **Type**, choisissez **Parameter (Paramètre)**. Pour **Nom**, saisissez `LOGIN_PASSWORD`. Pour le champ **Valeur**, saisissez `/CodeBuild/dockerLoginPassword`. Si vous utilisez Amazon EC2 Systems Manager Parameter Store, nous vous recommandons de stocker les paramètres avec des noms de paramètres commençant `/CodeBuild/` par (par exemple`/CodeBuild/dockerLoginPassword`,). Vous pouvez utiliser la CodeBuild console pour créer un paramètre dans Amazon EC2 Systems Manager. Choisissez **Create parameter (Créer un paramètre)**, puis suivez les instructions de la boîte de dialogue. (Dans cette boîte de dialogue, pour la **clé KMS**, vous pouvez spécifier l'ARN d'une AWS KMS clé dans votre compte. Amazon EC2 Systems Manager utilise cette clé pour chiffrer la valeur du paramètre pendant le stockage et pour la déchiffrer lors de la récupération.) Si vous utilisez la CodeBuild console pour créer un paramètre, la console commence par le nom du paramètre `/CodeBuild/` tel qu'il est enregistré. Pour plus d'informations, consultez la [procédure pas à pas de la console Systems Manager Parameter [Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) et Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console) dans le guide de l'*utilisateur d'Amazon EC2 Systems Manager*. Si votre projet de génération fait référence à des paramètres stockés dans Amazon EC2 Systems Manager Parameter Store, le rôle de service du projet de génération doit autoriser `ssm:GetParameters` l'action. Si vous avez sélectionné **Nouveau rôle de service** plus tôt, CodeBuild inclut cette action dans le rôle de service par défaut de votre projet de génération. En revanche, si vous avez choisi précédemment **Existing service role (Rôle de service existant)**, vous devez inclure séparément cette action dans votre rôle de service. Si votre projet de génération fait référence à des paramètres stockés dans Amazon EC2 Systems Manager Parameter Store avec des noms de paramètres qui ne commencent pas par`/CodeBuild/`, et que vous avez **choisi Nouveau rôle de service**, vous devez mettre à jour ce rôle de service pour autoriser l'accès aux noms de paramètres qui ne commencent pas par`/CodeBuild/`. En effet, ce rôle de service permet uniquement d'accéder aux noms de paramètres qui commencent par `/CodeBuild/`. Si vous choisissez **Nouveau rôle de service, le rôle** de service inclut l'autorisation de déchiffrer tous les paramètres sous l'espace de `/CodeBuild/` noms dans le magasin de paramètres Amazon EC2 Systems Manager. Les variables d'environnement que vous définissez remplacent les variables d'environnement existantes. Par exemple, si l'image Docker contient déjà une variable d'environnement nommée `MY_VAR` avec la valeur `my_value` et que vous définissez une variable d'environnement nommée `MY_VAR` avec la valeur `other_value`, la valeur `my_value` est remplacée par `other_value`. De même, si l'image Docker contient déjà une variable d'environnement nommée `PATH` avec la valeur `/usr/local/sbin:/usr/local/bin` et que vous définissez une variable d'environnement nommée `PATH` avec la valeur `$PATH:/usr/share/ant/bin`, la valeur `/usr/local/sbin:/usr/local/bin` est remplacée par la valeur littérale `$PATH:/usr/share/ant/bin`. Ne définissez pas de variables d'environnement avec un nom commençant par `CODEBUILD_`. Ce préfixe est réservé à une utilisation interne . Si une variable d'environnement avec le même nom est définie dans plusieurs emplacements, la valeur est déterminée comme suit : + La valeur de l'appel d'opération de démarrage de génération a une priorité plus élevée. + La valeur de la définition de projet de génération vient ensuite dans l'ordre des priorités. + La valeur figurant dans la déclaration buildspec a la priorité la plus faible. Si vous utilisez Secrets Manager, pour **Type**, choisissez **Secrets Manager**. Dans **Nom**, entrez un identifiant CodeBuild à référencer. Pour **Value (Valeur)**, saisissez un `reference-key` à l'aide du modèle `secret-id:json-key:version-stage:version-id`. Pour plus d'informations, consultez [Secrets Manager reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec). Si vous utilisez Secrets Manager, nous vous recommandons de stocker les secrets dont le nom commence par `/CodeBuild/` (par exemple,`/CodeBuild/dockerLoginPassword`). Pour plus d'informations, consultez [Présentation de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) dans le *Guide de l'utilisateur AWS Secrets Manager *. Si votre projet de génération fait référence à des secrets stockés dans Secrets Manager, le rôle de service du projet de génération doit autoriser l'`secretsmanager:GetSecretValue`action. Si vous avez sélectionné **Nouveau rôle de service** plus tôt, CodeBuild inclut cette action dans le rôle de service par défaut de votre projet de génération. En revanche, si vous avez choisi précédemment **Existing service role (Rôle de service existant)**, vous devez inclure séparément cette action dans votre rôle de service. Si votre projet de génération fait référence à des secrets stockés dans Secrets Manager avec des noms secrets qui ne commencent pas par`/CodeBuild/`, et que vous avez choisi **Nouveau rôle de service**, vous devez mettre à jour le rôle de service pour autoriser l'accès aux noms de secret qui ne commencent pas par`/CodeBuild/`. Cela est dû au fait que le rôle de service autorise l'accès uniquement aux noms secrets commençant par`/CodeBuild/`. Si vous choisissez **Nouveau rôle de service, le rôle** de service inclut l'autorisation de déchiffrer tous les secrets sous l'espace de `/CodeBuild/` noms dans le Gestionnaire de secrets. ### Spécifications de construction **Dans la section **Buildspec**, choisissez Modifier.** Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Vous pouvez modifier les propriétés suivantes : **Spécifications de construction** Effectuez l’une des actions suivantes : + Si votre code source inclut un fichier buildspec, choisissez **Utiliser un fichier buildspec**. Par défaut, CodeBuild recherche un fichier nommé `buildspec.yml` dans le répertoire racine de code source. Si votre fichier buildspec utilise un nom ou un emplacement différent, entrez son chemin depuis la racine source dans le **nom Buildspec (**par exemple, ou. `buildspec-two.yml` `configuration/buildspec.yml` Si le fichier buildspec se trouve dans un compartiment S3, il doit se trouver dans la même AWS région que votre projet de construction. Spécifiez le fichier buildspec à l'aide de son ARN (par exemple,). `arn:aws:s3:::/buildspec.yml` + Si votre code source ne comprend pas de fichier de spécification de génération ou si vous souhaitez exécuter des commandes de génération différentes de celles spécifiées pour la phase `build` dans le fichier `buildspec.yml` au sein du répertoire racine du code source, choisissez **Insérer des commandes de génération**. Pour **Build commands (Commandes de génération)**, saisissez les commandes que vous souhaitez exécuter lors de la phase `build`. Pour plusieurs commandes, séparez celles-ci avec `&&` (par exemple, `mvn test && mvn package`). Pour exécuter des commandes dans d'autres phases, ou si vous avez une longue liste de commandes pour la `build` phase, ajoutez un `buildspec.yml` fichier dans le répertoire racine du code source, ajoutez les commandes au fichier, puis choisissez **Utiliser le fichier buildspec.yml dans le répertoire racine du** code source. Pour de plus amples informations, veuillez consulter [Référence des spécifications de génération](build-spec-ref.md). ### Configuration par lots Dans la section **Configuration par lots**, choisissez **Modifier**. Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Pour de plus amples informations, veuillez consulter [Exécuter des builds par lots](batch-build.md). Vous pouvez modifier les propriétés suivantes : **Rôle du service Batch** Fournit le rôle de service pour les compilations par lots. Sélectionnez l’une des méthodes suivantes : + Si vous n'avez pas de rôle de service par lots, choisissez **Nouveau rôle de service**. Dans **Rôle de service**, entrez le nom du nouveau rôle. + Si vous avez un rôle de service par lots, choisissez **Rôle de service existant**. Dans **Rôle de service**, choisissez le rôle de service. Les générations en lot introduisent un nouveau rôle de sécurité dans la configuration par lots. Ce nouveau rôle est obligatoire car CodeBuild il doit être capable d'appeler les `RetryBuild` actions `StartBuild``StopBuild`, et en votre nom pour exécuter des builds dans le cadre d'un lot. Les clients doivent utiliser un nouveau rôle, et non le même rôle qu’ils utilisent dans leur build, pour deux raisons : + Donner au rôle de build `StartBuild`, `StopBuild` et `RetryBuild` les autorisations permettrait à une seule build de lancer davantage de builds via le buildspec. + CodeBuild les versions par lots fournissent des restrictions qui limitent le nombre de versions et les types de calcul qui peuvent être utilisés pour les versions du lot. Si le rôle de build dispose de ces autorisations, il est possible que les builds elles-mêmes puissent contourner ces restrictions. **Types de calcul autorisés pour le traitement par lots** Sélectionnez les types de calcul autorisés pour le lot. Sélectionnez toutes les réponses qui s'appliquent. **Flottes autorisées pour le lot** Sélectionnez les flottes autorisées pour le lot. Sélectionnez toutes les réponses qui s'appliquent. **Nombre maximal de builds autorisés par lot** Entrez le nombre maximum de builds autorisés dans le lot. Si un lot dépasse cette limite, il échouera. **Délai d'expiration du Batch** Entrez la durée maximale pendant laquelle la génération par lots doit être terminée. **Combinez des artefacts** Sélectionnez **Combiner tous les artefacts du lot en un seul emplacement** pour que tous les artefacts du lot soient combinés en un seul emplacement. **Mode de rapport par lots** Sélectionnez le mode de rapport d'état de construction souhaité pour les versions par lots. **Ce champ n'est disponible que lorsque la source du projet est Bitbucket ou GitHub Enterprise GitHub, et l'option **Signaler les statuts de construction au fournisseur de source lorsque le début et la fin de vos builds** sont sélectionnés sous Source.** **Constructions agrégées** Sélectionnez cette option pour que les statuts de toutes les versions du lot soient combinés dans un seul rapport d'état. **Constructions individuelles** Sélectionnez cette option pour que les statuts de toutes les versions du lot soient signalés séparément. ### Artefacts Dans la section **Artefacts**, choisissez **Modifier**. Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Vous pouvez modifier les propriétés suivantes : **Type** Effectuez l’une des actions suivantes : + Si vous ne souhaitez pas créer des artefacts de sortie de génération, choisissez **Aucun artefact**. Vous pouvez le faire si vous exécutez uniquement des tests de compilation ou si vous souhaitez transférer une image Docker vers un référentiel Amazon ECR. + Pour stocker le résultat du build dans un compartiment S3, choisissez **Amazon S3**, puis procédez comme suit : + Si vous souhaitez utiliser votre nom de projet pour le dossier ou le fichier ZIP de sortie de génération, ne renseignez pas le champ **Nom**. Sinon, entrez le nom. (Si vous souhaitez produire un fichier ZIP et que vous voulez que celui-ci ait une extension de fichier, veillez à l'inclure après le nom de fichier ZIP.) + Sélectionnez **Activer la gestion sémantique des versions** si vous voulez qu'un nom spécifié dans le fichier buildspec remplace le nom spécifié dans la console. Le nom figurant dans un fichier buildspec est calculé au moment de la génération et utilise le langage de commandes Shell. Par exemple, vous pouvez ajouter une date et une heure au nom de votre artefact afin qu'il soit toujours unique. Les noms d'artefact uniques empêchent les artefacts d'être écrasés. Pour de plus amples informations, veuillez consulter [Syntaxe d'un fichier buildspec](build-spec-ref.md#build-spec-ref-syntax). + Pour **Nom du compartiment**, choisissez le nom du compartiment de sortie. + Si vous avez sélectionné **Insérer des commandes de génération** précédemment dans cette procédure, pour **Fichiers de sortie**, saisissez les emplacements des fichiers de la génération que vous souhaitez placer dans le dossier ou le fichier ZIP de sortie de génération. Pour plusieurs emplacements, séparez ceux-ci avec une virgule (par exemple, `appspec.yml, target/my-app.jar`). Pour de plus amples informations, consultez la description de `files` dans [Syntaxe d'un fichier buildspec](build-spec-ref.md#build-spec-ref-syntax). + Si vous ne souhaitez pas que vos artefacts de génération soient chiffrés, choisissez **Remove artifacts encryption (Supprimer le chiffrement des artefacts)**. Pour chaque ensemble d'artefacts secondaire que vous souhaitez : 1. Pour **Artifact identifier (Identifiant d'artefact)**, saisissez une valeur de moins de 128 caractères et contenant uniquement des caractères alphanumériques et des traits de soulignement. 1. Choisissez **Add artifact (Ajouter un artefact)**. 1. Suivez les étapes précédentes pour configurer vos artefacts secondaires. 1. Choisissez **Save artifact (Enregistrer l'artefact)**. **Configuration supplémentaire** **Clé de chiffrement** Effectuez l’une des actions suivantes : + Pour utiliser l' Clé gérée par AWS Amazon S3 dans votre compte afin de chiffrer les artefacts de sortie du build, laissez la **clé de chiffrement** vide. Il s’agit de l’option par défaut. + Pour utiliser une clé gérée par le client pour chiffrer les artefacts de sortie de génération, dans **Clé de chiffrement**, entrez l'ARN de la clé gérée par le client. Utilisez le format `arn:aws:kms:region-ID:account-ID:key/key-ID`. **Type de cache** Pour **Cache type (Type de cache)**, choisissez l'une des valeurs suivantes : + Si vous ne souhaitez pas utiliser un cache, choisissez **Aucun cache**. + Si vous souhaitez utiliser un cache Amazon S3, choisissez **Amazon S3**, puis procédez comme suit : + Pour **Compartiment**, choisissez le nom du compartiment S3 dans lequel le cache est stocké. + (Facultatif) Pour **le préfixe de chemin du cache**, entrez un préfixe de chemin Amazon S3. La valeur **Cache path prefix (Préfixe du chemin de cache)** est semblable à un nom de répertoire. Cela vous permet de stocker le cache sous le même répertoire au sein d'un compartiment. **Important** N'ajoutez pas de barre oblique de fin (/) à la fin du préfixe du chemin. + Si vous souhaitez utiliser un cache local, choisissez **Local**, puis sélectionnez une ou plusieurs modes de cache local. **Note** Le mode de cache de couche Docker est disponible pour Linux uniquement. Si vous choisissez ce mode, votre projet doit être exécuté en mode privilégié. L'utilisation d'un cache permet de gagner beaucoup de temps de génération, car les parties réutilisables de l'environnement de génération sont stockées dans le cache et utilisées d'une génération à l'autre. Pour de plus amples informations sur la spécification d'un cache dans le fichier de spécification de génération, consultez [Syntaxe d'un fichier buildspec](build-spec-ref.md#build-spec-ref-syntax). Pour plus d'informations sur la mise en cache, consultez [Des mises en cache pour améliorer les performances](build-caching.md). ### Journaux Dans la section **Journaux**, choisissez **Modifier**. Lorsque vos modifications sont terminées, choisissez **Mettre à jour la configuration** pour enregistrer la nouvelle configuration. Vous pouvez modifier les propriétés suivantes : Choisissez les journaux que vous souhaitez créer. Vous pouvez créer des CloudWatch journaux Amazon Logs, des journaux Amazon S3 ou les deux. **CloudWatch** Si vous souhaitez obtenir CloudWatch les journaux Amazon Logs : **CloudWatch journaux** Sélectionnez **Journaux CloudWatch **. **Nom du groupe** Entrez le nom de votre groupe de CloudWatch journaux Amazon Logs. **Nom du stream** Entrez le nom de votre flux de journal Amazon CloudWatch Logs. **S3** Si vous souhaitez obtenir les journaux Amazon S3 : **Journaux S3** Sélectionnez **Journaux S3**. **Compartiment** Choisissez le nom du compartiment S3 pour vos journaux. **Préfixe de chemin** Entrez le préfixe de vos journaux. **Désactiver le chiffrement des journaux S3** Sélectionnez si vous ne voulez pas que vos journaux S3 soient chiffrés. ## Modification des paramètres d'un projet de génération (AWS CLI) Pour plus d'informations sur l'utilisation du AWS CLI with AWS CodeBuild, consultez le[Référence des commandes en ligne](cmd-ref.md). Pour mettre à jour un CodeBuild projet avec le AWS CLI, vous créez un fichier JSON avec les propriétés mises à jour et vous transmettez ce fichier à la [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html)commande. Toutes les propriétés qui ne figurent pas dans le fichier de mise à jour restent inchangées. Dans le fichier JSON de mise à jour, seules la `name` propriété et les propriétés modifiées sont requises. La `name` propriété identifie le projet à modifier. Pour toute structure modifiée, les paramètres requis pour ces structures doivent également être inclus. Par exemple, pour modifier l'environnement du projet, les `environment/computeType` propriétés `environment/type` et sont requises. Voici un exemple qui met à jour l'image de l'environnement : ``` { "name": "", "environment": { "type": "LINUX_CONTAINER", "computeType": "BUILD_GENERAL1_SMALL", "image": "aws/codebuild/amazonlinux-x86_64-standard:4.0" } } ``` Si vous devez obtenir les valeurs de propriétés actuelles d'un projet, utilisez la [https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html)commande pour obtenir les propriétés actuelles du projet que vous modifiez et écrivez le résultat dans un fichier. ``` aws codebuild batch-get-projects --names "" > project-info.json ``` Le *project-info.json* fichier contient un tableau de projets, il ne peut donc pas être utilisé directement pour mettre à jour un projet. Vous pouvez toutefois copier les propriétés que vous souhaitez modifier à partir du *project-info.json* fichier et les coller dans votre fichier de mise à jour comme référence pour les propriétés que vous souhaitez modifier. Pour de plus amples informations, veuillez consulter [Affichage des détails d'un projet de génération (AWS CLI)](view-project-details.md#view-project-details-cli). Modifiez le fichier JSON de mise à jour comme décrit dans[Création d'un projet de génération (AWS CLI)](create-project.md#create-project-cli), et enregistrez vos résultats. Lorsque vous avez terminé de modifier le fichier JSON de mise à jour, exécutez la [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html)commande en transmettant le fichier JSON de mise à jour. ``` aws codebuild update-project --cli-input-json file:// ``` En cas de succès, le JSON du projet mis à jour apparaît dans la sortie. Si des paramètres obligatoires sont manquants, un message d'erreur s'affiche dans la sortie pour identifier les paramètres manquants. Par exemple, voici le message d'erreur qui s'affiche si le `environment/type` paramètre est absent : ``` aws codebuild update-project --cli-input-json file://update-project.json Parameter validation failed: Missing required parameter in environment: "type" ``` ## Modification des paramètres d'un projet de génération (AWS SDKs) Pour plus d'informations sur l'utilisation AWS CodeBuild avec le AWS SDKs, consultez le[AWS SDKs et référence des outils](sdk-ref.md).