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.
Tutoriel : Configurer un CodeBuild-hosted GitLab coureur
Ce didacticiel explique comment configurer vos CodeBuild projets pour exécuter des tâches de GitLab CI/CD pipeline. Pour plus d'informations sur l'utilisation GitLab ou l' GitLab autogestion avec CodeBuild, consultezSelf-managed GitLab coureurs en AWS CodeBuild.
Pour effectuer ce didacticiel, vous devez d'abord :
-
Connectez-vous à une application OAuth à l'aide de. CodeConnections Notez que lorsque vous vous connectez à une application OAuth, vous devez utiliser la CodeBuild console pour le faire. Pour plus d’informations, consultez GitLab accès dans CodeBuild.
-
Connectez-vous CodeBuild à votre GitLab compte. Pour ce faire, vous pouvez l'ajouter GitLab en tant que fournisseur source dans la console. Pour obtenir des instructions, veuillez consulter GitLab accès dans CodeBuild.
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_runneretmanage_runnerdepuis l'application GitLab OAuth. S'il en existe CodeConnections pour un GitLab compte en particulier, il 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 au même GitLab compte pour déclencher la réautorisation afin d'obtenir les autorisations supplémentaires. Une fois cette étape terminée, toutes les connexions existantes peuvent utiliser la fonction Runner. Une fois que vous avez terminé, 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 consulter dans la GitLab console.
Pour créer un CodeBuild projet avec un webhook
Ouvrez la AWS CodeBuild console à l'adresse https://console.aws.amazon.com/codesuite/codebuild/home
. -
Créez un projet de génération. Pour plus d’informations, consultez Création d'un projet de génération (console) et Exécution d'une génération (console).
Dans Type de projet, choisissez Runner project.
-
Dans Runner :
-
Pour Runner provider, choisissez GitLab.
-
Pour les informations d'identification, choisissez l'une des options suivantes :
-
Choisissez Identifiant source par défaut. La connexion par défaut applique une GitLab connexion par défaut à tous les projets.
-
Choisissez Personnaliser les informations d'identification de la source. 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 en créer une nouvelle GitLab . Pour obtenir des instructions, veuillez consulter Connectez-vous CodeBuild à GitLab.
-
-
Pour Runner location, 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 prise en charge et calculez. Notez que vous avez la possibilité de modifier les paramètres d'image et d'instance en utilisant une étiquette dans le code YAML de votre GitLab CI/CD pipeline. Pour de plus amples informations, veuillez consulter Étape 2 : Créez un fichier .gitlab-ci.yml dans votre dépôt.
-
-
Dans Buildspec:
-
Notez que votre buildspec sera ignorée à moins qu'elle ne
buildspec-override:truesoit ajoutée en tant qu'étiquette. Au lieu de cela, il le CodeBuild remplacera pour utiliser des commandes qui configureront le coureur autogéré.
-
-
-
Continuez avec les valeurs par défaut, puis choisissez Créer un projet de construction.
-
Ouvrez la GitLab console à l'adresse
https://gitlab.com/pour vérifier qu'un webhook a été créé et qu'il est activé pour diffuser des événements liés aux tâches Workflow.user-name/repository-name/-/hooks
É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 GitLab
Mettez à jour votre GitLab CI/CD pipeline YAML
Accédez à votre référentiel https://gitlab.com/ et créez-en unuser-name/project-name/-/tree/branch-name.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 la compilation utilisera la configuration de votre 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 associer 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 permis d'invoquer des tâches avec les paramètres de projet corrects.
tags: - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAMEest 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 votre nom
<project-name>correspond au projet que vous avez créé dans CodeBuild. S'il ne correspond pas, le webhook ne CodeBuild sera pas traité et le GitLab CI/CD pipeline risque de se bloquer.Voici un exemple de GitLab CI/CD pipeline 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 votre type de calcul dans la balise. Consultez Calculez les images prises en charge par le CodeBuild-hosted GitLab runner la liste des images sélectionnées. Pour utiliser des images personnalisées, consultezLes remplacements d'étiquettes sont pris en charge avec le coureur CodeBuild-hosted GitLab. Le type de calcul et l'image contenus dans la balise remplaceront les paramètres d'environnement de votre projet. Pour modifier les paramètres de votre environnement pour une version de calcul Amazon EC2, utilisez la syntaxe suivante :
tags: - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:<environment-type>-<image-identifier>- instance-size:<instance-size>Voici un exemple de GitLab CI/CD pipeline 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 modifier la flotte utilisée pour votre build dans le tag. Cela remplacera les paramètres de flotte configurés sur votre projet pour utiliser la flotte spécifiée. Pour de plus amples informations, veuillez consulter Exécutez des builds sur des flottes à capacité réservée. Pour modifier les paramètres de votre flotte pour une version de calcul Amazon EC2, utilisez la syntaxe suivante :
tags: - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet:<fleet-name>Pour remplacer à la fois la flotte et l'image utilisées pour la génération, utilisez la syntaxe suivante :
tags: - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet:<fleet-name>- image:<environment-type>-<image-identifier>Voici un exemple de GitLab CI/CD pipeline 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 GitLab CI/CD pipeline 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 vous sera envoyée pour démarrer votre intégration. build-job CodeBuild
Exécutez les commandes buildspec dans les phases INSTALL, PRE_BUILD et POST_BUILD
Par défaut, CodeBuild ignore toutes les commandes buildspec lors de l'exécution d'une version autogérée. GitLab Pour exécuter les commandes buildspec pendant la compilation, buildspec-override:true vous pouvez ajouter un suffixe à : tags
tags: - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - buildspec-override:true
À l'aide de cette commande, CodeBuild vous allez créer un dossier appelé gitlab-runner dans le dossier source principal du conteneur. Lorsque le GitLab coureur prend le départ pendant la BUILD phase, il court dans le gitlab-runner répertoire.
L'utilisation d'un override buildspec dans une version autogérée présente plusieurs limites : GitLab
-
CodeBuild n'exécutera pas les commandes buildspec pendant la
BUILDphase, car le lanceur autogéré s'exécute pendant la phase.BUILD -
CodeBuild ne téléchargera aucune source primaire ou secondaire pendant la
DOWNLOAD_SOURCEphase. Si vous avez configuré un fichier buildspec, seul ce fichier sera téléchargé depuis la source principale du projet. -
Si une commande de génération échoue pendant la
INSTALLphasePRE_BUILDou, elle ne CodeBuild démarre pas le moteur d'exécution autogéré et la tâche du GitLab CI/CD pipeline doit être annulée manuellement. -
CodeBuild récupère le jeton du coureur pendant la
DOWNLOAD_SOURCEphase, dont le délai d'expiration est d'une heure. Si votre coursePRE_BUILDou vosINSTALLphases dépassent une heure, le jeton du coureur 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 est exécuté, CodeBuild reçoit les événements de la tâche du CI/CD pipeline via le webhook. Pour chaque tâche en CI/CD cours de préparation, CodeBuild démarre une construction pour exécuter un coureur éphémère GitLab . Le runner est responsable de l'exécution d'une seule tâche de CI/CD pipeline. Une fois la tâche terminée, le runner 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 dans GitLab, choisissez Build, Jobs, puis choisissez la tâche spécifique pour laquelle vous souhaitez consulter les journaux.
Vous pouvez consulter les libellés demandés dans le journal pendant que la tâche attend d'être prise en charge par un agent autogéré. CodeBuild
Filtrer les événements du GitLab webhook (CloudFormation)
La YAML-formatted partie suivante d'un CloudFormation
modèle crée un groupe de filtres qui déclenche une génération lorsqu'il est évalué à true. Le groupe de filtres suivant spécifie une demande de travail de GitLab CI/CD pipeline dont le nom de CI/CD pipeline correspond à 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\]