View a markdown version of this page

Tutorial: Konfiguriere einen CodeBuild-hosted GitLab Runner - AWS CodeBuild
Schritt 1: Erstellen Sie ein CodeBuild Projekt mit einem WebhookSchritt 2: Erstellen Sie eine .gitlab-ci.yml Datei in Ihrem RepositorySchritt 3: Überprüfe deine ErgebnisseGitLab Webhook-Ereignisse filtern (CloudFormation)

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Tutorial: Konfiguriere einen CodeBuild-hosted GitLab Runner

Dieses Tutorial zeigt Ihnen, wie Sie Ihre CodeBuild Projekte für die Ausführung von GitLab CI/CD Pipeline-Jobs konfigurieren. Weitere Informationen zur Verwendung GitLab oder zur GitLab Selbstverwaltung mit CodeBuild finden Sie unterSelf-managed GitLab Läufer in AWS CodeBuild.

Um dieses Tutorial abzuschließen, müssen Sie zunächst:

  • Stellen Sie eine Verbindung mit einer OAuth-App her, indem Sie verwenden. CodeConnections Beachten Sie, dass Sie beim Herstellen einer Verbindung mit einer OAuth-App dazu die CodeBuild Konsole verwenden müssen. Weitere Anweisungen finden Sie unter GitLab Zugriff auf CodeBuild.

  • Stellen Sie eine Verbindung CodeBuild zu Ihrem GitLab Konto her. Dazu können Sie in der Konsole einen Quellanbieter hinzufügen GitLab . Detaillierte Anweisungen finden Sie unter GitLab Zugriff auf CodeBuild.

    Anmerkung

    Dies muss nur getan werden, wenn Sie GitLab für Ihr Konto keine Verbindung hergestellt haben.

    Für diese Funktion sind zusätzliche CodeBuild Berechtigungen erforderlich, z. B. create_runner und manage_runner von der GitLab OAuth-App. Wenn diese CodeConnections für ein bestimmtes GitLab Konto existieren, werden nicht automatisch Genehmigungsaktualisierungen angefordert. Dazu können Sie zur CodeConnections Konsole gehen und eine Dummy-Verbindung zu demselben GitLab Konto herstellen, um die erneute Autorisierung auszulösen und die zusätzlichen Berechtigungen zu erhalten. Nach Abschluss dieses Schritts können alle vorhandenen Verbindungen die Runner-Funktion verwenden. Sobald Sie fertig sind, können Sie die Dummy-Verbindung löschen.

Schritt 1: Erstellen Sie ein CodeBuild Projekt mit einem Webhook

In diesem Schritt erstellen Sie ein CodeBuild Projekt mit einem Webhook und überprüfen es in der GitLab Konsole.

Um ein CodeBuild Projekt mit einem Webhook zu erstellen

  1. Öffnen Sie die AWS CodeBuild Konsole unter. https://console.aws.amazon.com/codesuite/codebuild/home

  2. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter Erstellen Sie ein Build-Projekt (Konsole) und Ausführen eines Build (Konsole).

    Wählen Sie unter Projekttyp die Option Runner-Projekt aus.

    • In Runner:

      • Wählen Sie als Runner-Anbieter GitLab.

      • Wählen Sie für Credential eine der folgenden Optionen aus:

        • Wählen Sie Standard-Quell-Anmeldeinformationen aus. Bei der Standardverbindung wird eine GitLab Standardverbindung auf alle Projekte angewendet.

        • Wählen Sie Benutzerdefinierte Quellanmeldeinformationen. Bei der benutzerdefinierten Verbindung wird eine benutzerdefinierte GitLab Verbindung angewendet, die die Standardeinstellungen Ihres Kontos außer Kraft setzt.

        Anmerkung

        Wenn Sie noch keine Verbindung zu Ihrem Anbieter hergestellt haben, müssen Sie eine neue GitLab Verbindung herstellen. Detaillierte Anweisungen finden Sie unter Stellen Sie eine Verbindung CodeBuild her GitLab.

      • Wählen Sie für den Standort des Runners die Option Repository aus.

      • Wählen Sie für Repository den Namen Ihres Projekts in, GitLab indem Sie den Projektpfad mit dem Namespace angeben.

    • In Environment (Umgebung):

    • In Buildspec (Build-Spezifikation):

      • Beachten Sie, dass Ihre Buildspec ignoriert wird, sofern sie nicht als Label hinzugefügt buildspec-override:true wird. Stattdessen überschreibt es, CodeBuild um Befehle zu verwenden, die den selbstverwalteten Runner einrichten.

  3. Fahren Sie mit den Standardwerten fort und wählen Sie dann Create build project.

  4. Öffnen Sie die GitLab Konsole unter, https://gitlab.com/user-name/repository-name/-/hooks um zu überprüfen, ob ein Webhook erstellt wurde und für die Übermittlung von Workflow-Auftragsereignissen aktiviert ist.

Schritt 2: Erstellen Sie eine .gitlab-ci.yml Datei in Ihrem Repository

In diesem Schritt erstellen Sie eine .gitlab-ci.yml Datei, in der Sie Ihre Build-Umgebung konfigurieren und GitLab selbstverwaltete Runner verwenden können. GitLab CodeBuild Weitere Informationen finden Sie unter Verwenden Sie selbstverwaltete Runner.

Aktualisieren Sie Ihre GitLab CI/CD Pipeline YAML

Navigiere zu deinem Repository https://gitlab.com/user-name/project-name/-/tree/branch-name und erstelle eine .gitlab-ci.yml Datei in deinem Repository. Sie können Ihre Build-Umgebung konfigurieren, indem Sie einen der folgenden Schritte ausführen:

  • Sie können den CodeBuild Projektnamen angeben. In diesem Fall verwendet der Build Ihre bestehende Projektkonfiguration für die Berechnung, das Image, die Image-Version und die Instanzgröße. Der Projektname wird benötigt, um die AWS zugehörigen Einstellungen Ihres GitLab Jobs mit einem bestimmten CodeBuild Projekt zu verknüpfen. Durch die Aufnahme des Projektnamens in die YAML CodeBuild ist es möglich, Jobs mit den richtigen Projekteinstellungen aufzurufen.

    tags:
    - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME

    $CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAMEist erforderlich, um den Build bestimmten Pipeline-Jobläufen zuzuordnen und den Build zu stoppen, wenn der Pipeline-Lauf abgebrochen wird.

    Anmerkung

    Stellen Sie sicher, dass Ihr <project-name> mit dem Namen des Projekts übereinstimmt, in dem Sie es erstellt haben CodeBuild. Wenn er nicht übereinstimmt, CodeBuild wird der Webhook nicht verarbeitet und die GitLab CI/CD Pipeline hängt möglicherweise.

    Das Folgende ist ein Beispiel für eine 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

  • Sie können auch Ihr Bild überschreiben und den Typ im Tag berechnen. Eine Liste der kuratierten Bilder finden Sie unterBerechnet Bilder, die vom Runner unterstützt werden CodeBuild-hosted GitLab. Informationen zur Verwendung benutzerdefinierter Bilder finden Sie unterLabel-Overrides werden vom Runner unterstützt CodeBuild-hosted GitLab. Der Berechnungstyp und das Bild im Tag überschreiben die Umgebungseinstellungen in Ihrem Projekt. Verwenden Sie die folgende Syntax, um Ihre Umgebungseinstellungen für einen Amazon EC2-Compute-Build zu überschreiben:

    tags:
    - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
    - image:<environment-type>-<image-identifier>
    - instance-size:<instance-size>

    Das Folgende ist ein Beispiel für eine 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

  • Sie können die für Ihren Build verwendete Flotte im Tag überschreiben. Dadurch werden die in deinem Projekt konfigurierten Flotteneinstellungen überschrieben, sodass die angegebene Flotte verwendet wird. Weitere Informationen finden Sie unter Führen Sie Builds auf Flotten mit reservierter Kapazität aus. Verwenden Sie die folgende Syntax, um Ihre Flotteneinstellungen für einen Amazon EC2-Rechenbuild zu überschreiben:

    tags:
    - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
    - fleet:<fleet-name>

    Verwenden Sie die folgende Syntax, um sowohl die Flotte als auch das für den Build verwendete Image zu überschreiben:

    tags:
    - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
    - fleet:<fleet-name>                    
    - image:<environment-type>-<image-identifier>

    Das Folgende ist ein Beispiel für eine 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

  • Um Ihre GitLab CI/CD Pipeline-Jobs auf einem benutzerdefinierten Image auszuführen, können Sie ein benutzerdefiniertes Image in Ihrem CodeBuild Projekt konfigurieren und vermeiden, ein Image-Override-Label bereitzustellen. CodeBuild verwendet das im Projekt konfigurierte Image, wenn kein Image-Override-Label bereitgestellt wird.

Nachdem Sie Ihre Änderungen bestätigt haben.gitlab-ci.yml, wird eine GitLab Pipeline ausgelöst und eine Webhook-Benachrichtigung gesendet, mit der build-job Ihr Build gestartet wird. CodeBuild

Führen Sie die Buildspec-Befehle in den Phasen INSTALL, PRE_BUILD und POST_BUILD aus

CodeBuild Ignoriert standardmäßig alle Buildspec-Befehle, wenn ein selbstverwalteter Build ausgeführt wird. GitLab Um Buildspec-Befehle während des Builds auszuführen, können sie als Suffix hinzugefügt werden zu: buildspec-override:true tags

tags:
    - codebuild-<codebuild-project-name>-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
    - buildspec-override:true

Mit diesem Befehl CodeBuild wird ein Ordner mit dem Namen gitlab-runner im primären Quellordner des Containers erstellt. Wenn der GitLab Runner während der BUILD Phase startet, wird der Runner im gitlab-runner Verzeichnis ausgeführt.

Bei der Verwendung einer Buildspec-Override in einem selbstverwalteten Build gibt es mehrere Einschränkungen: GitLab

  • CodeBuild führt während der Phase keine Buildspec-Befehle aus, da der selbstverwaltete Runner in der BUILD Phase ausgeführt wird. BUILD

  • CodeBuild lädt während der Phase keine primären oder sekundären Quellen herunter. DOWNLOAD_SOURCE Wenn Sie eine Buildspec-Datei konfiguriert haben, wird nur diese Datei von der Hauptquelle des Projekts heruntergeladen.

  • Wenn ein Build-Befehl in der PRE_BUILD INSTALL OR-Phase fehlschlägt, CodeBuild wird der selbstverwaltete Runner nicht gestartet und der GitLab CI/CD Pipeline-Job muss manuell abgebrochen werden.

  • CodeBuild ruft das Runner-Token während der DOWNLOAD_SOURCE Phase ab, die eine Ablaufzeit von einer Stunde hat. Wenn deine PRE_BUILD oder INSTALL Phasen eine Stunde überschreiten, läuft das Runner-Token möglicherweise ab, bevor der GitLab selbstverwaltete Runner startet.

Schritt 3: Überprüfe deine Ergebnisse

Jedes Mal, wenn ein GitLab CI/CD Pipeline-Lauf stattfindet, CodeBuild würden die CI/CD Pipeline-Job-Ereignisse über den Webhook empfangen. CodeBuild Startet für jeden Job in der CI/CD Pipeline einen Build, um einen kurzlebigen GitLab Runner auszuführen. Der Runner ist für die Ausführung eines einzelnen CI/CD Pipeline-Jobs verantwortlich. Sobald der Job abgeschlossen ist, werden der Runner und der zugehörige Build-Prozess sofort beendet.

Um Ihre CI/CD Pipeline-Job-Logs einzusehen, navigieren Sie zu Ihrem Repository in GitLab, wählen Sie Build, Jobs und wählen Sie dann den spezifischen Job aus, für den Sie die Logs überprüfen möchten.

Du kannst die angeforderten Labels im Log überprüfen, während der Job darauf wartet, von einem selbst verwalteten Run-In CodeBuild abgeholt zu werden.

GitLab Webhook-Ereignisse filtern (CloudFormation)

Im folgenden YAML-formatted Teil einer CloudFormation Vorlage wird eine Filtergruppe erstellt, die einen Build auslöst, wenn das Ergebnis „Wahr“ ergibt. Die folgende Filtergruppe spezifiziert eine GitLab CI/CD Pipeline-Jobanforderung mit einem CI/CD Pipeline-Namen, der dem regulären Ausdruck \[CI-CodeBuild\] entspricht.

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\]