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. # GitLab Coureurs autogérés en AWS CodeBuild GitLab propose deux modes d'exécution pour exécuter GitLab des tâches dans votre CI/CD pipeline. L'un des modes est celui des coureurs GitLab hébergés, qui sont gérés par GitLab et entièrement intégrés à GitLab. L'autre mode est celui des coureurs autogérés, qui vous permet de créer votre propre environnement personnalisé pour exécuter des tâches dans le pipeline GitLab CI/CD. Les étapes de haut niveau pour configurer un CodeBuild projet afin d'exécuter des tâches de pipeline GitLab CI/CD sont les suivantes : 1. Si ce n'est pas déjà fait, connectez-vous à l'aide d'une OAuth application à laquelle connecter votre projet GitLab. 1. Accédez à la CodeBuild console, créez un CodeBuild projet avec un webhook et configurez vos filtres webhook. 1. Mettez à jour votre pipeline GitLab CI/CD YAML GitLab pour configurer votre environnement de construction. Pour une procédure plus détaillée, voir[Tutoriel : Configuration d'un CodeBuild coureur hébergé GitLab](sample-gitlab-runners.md). Cette fonctionnalité permet à vos tâches de pipeline GitLab CI/CD de s'intégrer de manière native AWS, ce qui garantit sécurité et commodité grâce à des fonctionnalités telles que IAM AWS CloudTrail et Amazon VPC. Vous pouvez accéder aux derniers types d'instances, y compris les instances basées sur ARM. **Topics** + [À propos du CodeBuild coureur hébergé GitLab](gitlab-runner-questions.md) + [Tutoriel : Configuration d'un CodeBuild coureur hébergé GitLab](sample-gitlab-runners.md) + [Les remplacements d'étiquettes sont pris en charge par le CodeBuild coureur hébergé GitLab](gitlab-runners-update-labels.md) + [Calculer les images prises en charge par le logiciel CodeBuild -hosted runner GitLab](sample-gitlab-runners-gitlab-ci.images.md) # À propos du CodeBuild coureur hébergé GitLab Voici quelques questions courantes concernant le CodeBuild GitLab coureur hébergé. ## Quels types de sources sont pris en charge pour les GitLab coureurs CodeBuild hébergés ? CodeBuild GitLab -les coureurs hébergés sont pris en charge pour le type `GITLAB` et `GITLAB_SELF_MANAGED` source. ## Quand dois-je inclure les remplacements d'image et d'instance dans l'étiquette ? Vous pouvez inclure les remplacements d'image et d'instance dans l'étiquette afin de spécifier un environnement de construction différent pour chacune de vos tâches de pipeline GitLab CI/CD. Cela peut être fait sans qu'il soit nécessaire de créer plusieurs CodeBuild projets ou webhooks. ## Puis-je utiliser CloudFormation cette fonctionnalité ? Oui, vous pouvez inclure un groupe de filtres dans votre CloudFormation modèle qui spécifie un GitLab filtre d'événements de travail dans le webhook de votre projet. ``` Triggers: Webhook: true FilterGroups: - - Type: EVENT Pattern: WORKFLOW_JOB_QUEUED ``` Pour de plus amples informations, veuillez consulter [Filtrer les événements du GitLab webhook ()CloudFormation](gitlab-webhook-events-cfn.md). Si vous avez besoin d'aide pour configurer les informations d'identification du projet dans votre CloudFormation modèle, consultez [AWS::CodeBuild::SourceCredential](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-sourcecredential.html)le *guide de AWS CloudFormation l'utilisateur* pour plus d'informations. ## Comment masquer des secrets lors de l'utilisation de cette fonctionnalité ? Par défaut, les secrets imprimés dans le journal ne sont pas masqués. Si vous souhaitez masquer vos secrets, vous pouvez le faire en mettant à jour les paramètres de vos variables d' CI/CD environnement : **Pour masquer des secrets GitLab** 1. Dans vos **GitLab paramètres**, choisissez **CI/CD**. 1. Dans **Variables**, choisissez **Modifier** pour le secret que vous souhaitez masquer. 1. Dans **Visibilité**, sélectionnez **Variable de masque**, puis choisissez **Mettre à jour la variable** pour enregistrer vos modifications. ## Puis-je recevoir des événements GitLab webhook issus de plusieurs projets au sein d'un même groupe ? CodeBuild prend en charge les webhooks de groupe, qui reçoivent des événements d'un GitLab groupe spécifié. Pour de plus amples informations, veuillez consulter [GitLab webhooks de groupe](gitlab-group-webhook.md). ## Puis-je exécuter une tâche dans Docker Executor pour le runner autogéré ? Par exemple, je souhaite exécuter une tâche de pipeline sur une image spécifique afin de conserver le même environnement de construction dans un conteneur séparé et isolé. Vous pouvez exécuter le GitLab runner autogéré CodeBuild avec une image spécifique en [créant le projet avec une image personnalisée](create-project.md#environment-image.console) ou en [remplaçant l'image](sample-gitlab-runners.md#sample-gitlab-runners-gitlab-ci) dans votre `.gitlab-ci.yml` fichier. ## Avec quel exécuteur testamentaire CodeBuild court le coureur autogéré ? Le runner autogéré CodeBuild s'exécute avec l'exécuteur shell, où le build s'exécute localement avec le GitLab runner qui s'exécute dans le conteneur docker. ## Puis-je fournir des commandes buildspec avec le runner autogéré ? Oui, il est possible d'ajouter des commandes buildspec avec un runner autogéré. Vous pouvez fournir le fichier buildspec.yml dans votre GitLab dépôt et utiliser la `buildspec-override:true` balise dans la section **Tags** de la tâche. Pour de plus amples informations, veuillez consulter [Nom de fichier buildspec et emplacement de stockage](build-spec-ref.md#build-spec-ref-name-storage). ## Quelles sont les régions où l'utilisation d'un GitLab coureur CodeBuild hébergé est prise en charge ? CodeBuild GitLab -les coureurs hébergés sont soutenus dans toutes les CodeBuild régions. Pour plus d'informations sur Régions AWS les CodeBuild zones disponibles, consultez la section [AWS Services par région](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). ## Quelles plateformes prennent en charge l'utilisation d'un CodeBuild GitLab coureur hébergé ? CodeBuild GitLab -les coureurs hébergés sont pris en charge à la fois sur Amazon EC2 [AWS Lambda](lambda.md)et sur Compute. Vous pouvez utiliser les plateformes suivantes : Amazon Linux 2, Amazon Linux 2023, Ubuntu et Windows Server Core 2019. Pour plus d’informations, consultez [images de calcul EC2](ec2-compute-images.md) et [Images de calcul Lambda](lambda-compute-images.md). # Tutoriel : Configuration d'un CodeBuild coureur hébergé GitLab Ce didacticiel explique comment configurer vos CodeBuild projets pour exécuter des tâches de pipeline GitLab CI/CD. Pour plus d'informations sur l'utilisation GitLab ou l' GitLab autogestion avec CodeBuild, consultez[GitLab Coureurs autogérés en AWS CodeBuild](gitlab-runner.md). Pour effectuer ce didacticiel, vous devez d'abord : + Connectez-vous à une OAuth application en utilisant CodeConnections. Notez que lorsque vous vous connectez à une OAuth application, vous devez utiliser la CodeBuild console pour ce faire. Pour plus d’informations, consultez [GitLab accéder à CodeBuild](access-tokens-gitlab-overview.md). + Connectez-vous CodeBuild à votre GitLab compte. Pour ce faire, vous pouvez l'ajouter GitLab en tant que fournisseur de source dans la console. Pour obtenir des instructions, veuillez consulter [GitLab accéder à CodeBuild](access-tokens-gitlab-overview.md). **Note** Cela ne doit être fait que si vous n'êtes pas connecté GitLab à votre compte. Cette fonctionnalité CodeBuild nécessite des autorisations supplémentaires, telles que `create_runner` et `manage_runner` depuis l' GitLab OAuth application. S'il en existe CodeConnections pour un GitLab compte en particulier, celui-ci ne demande pas automatiquement de mises à jour des autorisations. Pour ce faire, vous pouvez accéder à la CodeConnections console et créer une connexion fictive avec le même GitLab compte pour déclencher la réautorisation afin d'obtenir les autorisations supplémentaires. Ainsi, toutes les connexions existantes peuvent utiliser la fonction Runner. Une fois l'opération terminée, vous pouvez supprimer la connexion fictive. ## Étape 1 : Création d'un CodeBuild projet avec un webhook Au cours de cette étape, vous allez créer un CodeBuild projet avec un webhook et le passer en revue dans la GitLab console. **Pour créer un CodeBuild projet avec un webhook** 1. Ouvrez la AWS CodeBuild console sur [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home). 1. Créez un projet de génération. Pour plus d’informations, consultez [Création d'un projet de génération (console)](create-project.md#create-project-console) et [Exécution d'une génération (console)](run-build-console.md). Dans **Type de projet**, choisissez le **projet Runner**. + Dans **Runner** : + Pour le **fournisseur Runner**, choisissez **GitLab**. + Pour **Credential**, sélectionnez l'une des options suivantes : + Choisissez les informations d'**identification de source par défaut**. La connexion par défaut applique une GitLab connexion par défaut à tous les projets. + Choisissez Informations d'**identification source personnalisées**. La connexion personnalisée applique une GitLab connexion personnalisée qui remplace les paramètres par défaut de votre compte. **Note** Si vous n'avez pas encore créé de connexion avec votre fournisseur, vous devrez créer une nouvelle GitLab connexion. Pour obtenir des instructions, veuillez consulter [Connect CodeBuild à GitLab](access-tokens-gitlab-overview.md#connections-gitlab). + Pour l'**emplacement de Runner**, choisissez **Repository**. + Pour **Repository**, choisissez le nom de votre projet en GitLab spécifiant le chemin du projet avec l'espace de noms. + Dans **Environment (Environnement)** : + Choisissez une **image d'environnement** compatible et **calculez**. Notez que vous avez la possibilité de remplacer les paramètres d'image et d'instance en utilisant une étiquette dans le YAML de votre pipeline GitLab CI/CD. Pour de plus amples informations, veuillez consulter [Étape 2 : Créez un fichier .gitlab-ci.yml dans votre dépôt](#sample-gitlab-runners-gitlab-ci). + Dans **Buildspec**: + Notez que votre spécification de construction sera ignorée à moins qu'elle ne `buildspec-override:true` soit ajoutée sous forme d'étiquette. Au lieu de cela, il le CodeBuild remplacera pour utiliser des commandes qui configureront le coureur autogéré. 1. Continuez avec les valeurs par défaut, puis choisissez **Create build project**. 1. Ouvrez la GitLab console sur `https://gitlab.com/user-name/repository-name/-/hooks` pour vérifier qu'un webhook a été créé et qu'il est activé pour diffuser des événements de **tâches Workflow**. ## Étape 2 : Créez un fichier .gitlab-ci.yml dans votre dépôt Au cours de cette étape, vous allez créer un `.gitlab-ci.yml` fichier dans lequel vous [https://gitlab.com/](https://gitlab.com/)allez configurer votre environnement de construction et utiliser des runners GitLab autogérés. CodeBuild Pour plus d'informations, consultez la section [Utiliser des coureurs autogérés](https://docs.gitlab.com/runner/#use-self-managed-runners). ### Mettez à jour votre pipeline GitLab CI/CD YAML Accédez à votre référentiel `https://gitlab.com/user-name/project-name/-/tree/branch-name` et créez-en un`.gitlab-ci.yml`. Vous pouvez configurer votre environnement de génération en effectuant l'une des opérations suivantes : + Vous pouvez spécifier le nom du CodeBuild projet, auquel cas le build utilisera votre configuration de projet existante pour le calcul, l'image, la version de l'image et la taille de l'instance. Le nom du projet est nécessaire pour lier les AWS paramètres associés à votre GitLab tâche à un CodeBuild projet spécifique. En incluant le nom du projet dans le YAML, CodeBuild il est autorisé à invoquer des tâches avec les paramètres de projet corrects. ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME ``` `$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`est nécessaire pour mapper la construction à des exécutions de tâches de pipeline spécifiques et arrêter la génération lorsque l'exécution du pipeline est annulée. **Note** Assurez-vous que le nom du projet que vous avez créé ** correspond à celui dans lequel vous l'avez créé CodeBuild. S'il ne correspond pas, le webhook ne CodeBuild sera pas traité et le pipeline GitLab CI/CD risque de se bloquer. Voici un exemple de pipeline GitLab CI/CD YAML : ``` workflow: name: HelloWorld stages: # List of stages for jobs, and their order of execution - build build-job: # This job runs in the build stage, which runs first. stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME ``` + Vous pouvez également remplacer votre image et le type de calcul dans la balise. Consultez [Calculer les images prises en charge par le logiciel CodeBuild -hosted runner GitLab](sample-gitlab-runners-gitlab-ci.images.md) la liste des images sélectionnées. Pour utiliser des images personnalisées, voir[Les remplacements d'étiquettes sont pris en charge par le CodeBuild coureur hébergé GitLab](gitlab-runners-update-labels.md). Le type de calcul et l'image contenus dans la balise remplaceront les paramètres d'environnement de votre projet. Pour remplacer les paramètres de votre environnement pour une version de calcul Amazon EC2, utilisez la syntaxe suivante : ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:- - instance-size: ``` Voici un exemple de pipeline GitLab CI/CD YAML : ``` stages: - build build-job: stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:arm-3.0 - instance-size:small ``` + Vous pouvez remplacer la flotte utilisée pour votre build dans le tag. Cela remplacera les paramètres de flotte configurés dans votre projet pour utiliser le parc spécifié. Pour de plus amples informations, veuillez consulter [Exécutez des builds sur des flottes à capacité réservée](fleets.md). Pour remplacer les paramètres de votre flotte pour une version de calcul Amazon EC2, utilisez la syntaxe suivante : ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet: ``` Pour remplacer à la fois la flotte et l'image utilisées pour la génération, utilisez la syntaxe suivante : ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet: - image:- ``` Voici un exemple de pipeline GitLab CI/CD YAML : ``` stages: - build build-job: stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet:myFleet - image:arm-3.0 ``` + Pour exécuter vos tâches de pipeline GitLab CI/CD sur une image personnalisée, vous pouvez configurer une image personnalisée dans votre CodeBuild projet et éviter de fournir une étiquette de remplacement d'image. CodeBuild utilisera l'image configurée dans le projet si aucune étiquette de remplacement d'image n'est fournie. Une fois que vous aurez validé vos modifications`.gitlab-ci.yml`, un GitLab pipeline sera déclenché et une notification Webhook sera envoyée pour démarrer votre build in CodeBuild. `build-job` ### Exécutez les commandes buildspec pendant les phases INSTALL, PRE\$1BUILD et POST\$1BUILD Par défaut, CodeBuild ignore les commandes buildspec lors de l'exécution d'une version autogérée. GitLab Pour exécuter les commandes buildspec pendant la construction, `buildspec-override:true` vous pouvez les ajouter en tant que suffixe à : `tags` ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - buildspec-override:true ``` En utilisant cette commande, CodeBuild vous créerez un dossier appelé `gitlab-runner` dans le dossier source principal du conteneur. Lorsque le GitLab coureur démarre pendant la `BUILD` phase, il court dans le `gitlab-runner` répertoire. L'utilisation d'une dérogation buildspec dans une version autogérée présente plusieurs limites : GitLab + CodeBuild n'exécutera pas de commandes buildspec pendant la `BUILD` phase, car le lanceur autogéré s'exécute pendant la phase. `BUILD` + CodeBuild ne téléchargera aucune source principale ou secondaire pendant la `DOWNLOAD_SOURCE` phase. Si vous avez configuré un fichier buildspec, seul ce fichier sera téléchargé depuis la source principale du projet. + Si une commande de construction échoue pendant la `INSTALL` phase `PRE_BUILD` ou, elle ne CodeBuild démarrera pas le lanceur autogéré et la tâche du pipeline GitLab CI/CD devra être annulée manuellement. + CodeBuild récupère le jeton du coureur pendant la `DOWNLOAD_SOURCE` phase, dont le délai d'expiration est d'une heure. Si votre `PRE_BUILD` ou vos `INSTALL` phases dépassent une heure, le jeton de course peut expirer avant le départ du coureur GitLab autogéré. ## Étape 3 : Passez en revue vos résultats Chaque fois qu'un GitLab CI/CD pipeline run occurs, CodeBuild would receive the CI/CD pipeline job events through the webhook. For each job in the CI/CD pipeline, CodeBuild starts a build to run an ephemeral GitLab runner. The runner is responsible for executing a single CI/CD projet de pipeline est effectué. Une fois le travail terminé, le lanceur et le processus de construction associé seront immédiatement interrompus. Pour consulter les journaux des tâches de votre CI/CD pipeline, accédez à votre référentiel GitLab, choisissez **Build**, **Jobs**, puis choisissez le **Job** spécifique dont vous souhaitez consulter les journaux. Vous pouvez consulter les étiquettes demandées dans le journal pendant que le travail attend d'être récupéré par un coureur autogéré. CodeBuild ## Filtrer les événements du GitLab webhook ()CloudFormation La partie suivante d'un CloudFormation modèle au format YAML crée un groupe de filtres qui déclenche une génération lorsqu'elle est évaluée à true. Le groupe de filtres suivant spécifie un nom de GitLab CI/CD pipeline job request with a CI/CD pipeline correspondant à l'expression régulière`\[CI-CodeBuild\]`. ``` CodeBuildProject: Type: AWS::CodeBuild::Project Properties: Name: MyProject ServiceRole: service-role Artifacts: Type: NO_ARTIFACTS Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/standard:5.0 Source: Type: GITLAB Location: CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION Triggers: Webhook: true ScopeConfiguration: Name: group-name Scope: GITLAB_GROUP FilterGroups: - - Type: EVENT Pattern: WORKFLOW_JOB_QUEUED - Type: WORKFLOW_NAME Pattern: \[CI-CodeBuild\] ``` # Les remplacements d'étiquettes sont pris en charge par le CodeBuild coureur hébergé GitLab Dans votre pipeline GitLab CI/CD YAML, vous pouvez fournir une variété de remplacements d'étiquettes qui modifient votre build de runner autogéré. Toutes les versions non reconnues par CodeBuild seront ignorées mais n'échoueront pas à votre demande de webhook. Par exemple, le code YAML suivant inclut les remplacements relatifs à l'image, à la taille de l'instance, au parc et aux spécifications de construction : ``` workflow: name: HelloWorld stages: - build build-job: stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:arm-3.0 - instance-size:small - fleet:myFleet - buildspec-override:true ``` `codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME` (obligatoire) + Exemple : `codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME` + Nécessaire pour tous les GitLab pipelines CI/CD. YAMLs **doit être égal au nom du projet pour lequel le runner webhook autogéré est configuré. `image:-` + Exemple : `image:arm-3.0` + Remplace l'image et le type d'environnement utilisés lors du démarrage de la version autogérée du runner. Pour en savoir plus sur les valeurs prises en charge, consultez[Calculer les images prises en charge par le logiciel CodeBuild -hosted runner GitLab](sample-gitlab-runners-gitlab-ci.images.md). + Pour remplacer l'image et le type d'environnement utilisés par une image personnalisée, utilisez `image:custom--` + Exemple : `image:custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0` **Note** Si l'image personnalisée se trouve dans un registre privé, consultez[Configurer un identifiant de registre privé pour les coureurs auto-hébergés](private-registry-sample-configure-runners.md). `instance-size:` + Exemple : `instance-size:small` + Remplace le type d'instance utilisé lors du démarrage de la version autogérée du runner. Pour en savoir plus sur les valeurs prises en charge, consultez[Calculer les images prises en charge par le logiciel CodeBuild -hosted runner GitLab](sample-gitlab-runners-gitlab-ci.images.md). `fleet:` + Exemple : `fleet:myFleet` + Remplace les paramètres de flotte configurés dans votre projet pour utiliser le parc spécifié. Pour de plus amples informations, veuillez consulter [Exécutez des builds sur des flottes à capacité réservée](fleets.md). `buildspec-override:` + Exemple : `buildspec-override:true` + Permet à la compilation d'exécuter des commandes buildspec dans les `POST_BUILD` phases `INSTALL``PRE_BUILD`, et si elle est définie sur. `true` # Calculer les images prises en charge par le logiciel CodeBuild -hosted runner GitLab Dans l'étiquette que vous avez configurée[Tutoriel : Configuration d'un CodeBuild coureur hébergé GitLab](sample-gitlab-runners.md), vous pouvez remplacer les paramètres de votre environnement Amazon EC2 en utilisant les valeurs des trois premières colonnes. CodeBuild fournit les images de calcul Amazon EC2 suivantes. Pour plus d'informations sur [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html) En outre, vous pouvez modifier les paramètres de votre environnement Lambda en utilisant les valeurs suivantes. Pour plus d'informations sur le calcul CodeBuild Lambda, consultez. [Exécuter des builds sur AWS Lambda ordinateur](lambda.md) CodeBuild prend en charge les images de calcul Lambda suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html) Pour plus d’informations, consultez [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md) et [Images Docker fournies par CodeBuild](build-env-ref-available.md).