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. # Selbstverwaltete Läufer GitLab in AWS CodeBuild GitLab bietet zwei Ausführungsmodi zum Ausführen von GitLab Jobs in Ihrer CI/CD Pipeline. Ein Modus besteht aus GitLab gehosteten Runnern, die von verwaltet werden GitLab und vollständig in diese integriert GitLab sind. Bei dem anderen Modus handelt es sich um selbstverwaltete Runner, mit denen Sie Ihre eigene benutzerdefinierte Umgebung verwenden können, um Jobs in der GitLab CI/CD-Pipeline auszuführen. Die allgemeinen Schritte zur Konfiguration eines CodeBuild Projekts für die Ausführung von GitLab CI/CD-Pipeline-Jobs lauten wie folgt: 1. Falls Sie dies noch nicht getan haben, stellen Sie eine Verbindung mit einer OAuth App her, mit der Sie Ihr Projekt verbinden möchten. GitLab 1. Navigieren Sie zur CodeBuild Konsole, erstellen Sie ein CodeBuild Projekt mit einem Webhook und richten Sie Ihre Webhook-Filter ein. 1. Aktualisieren Sie Ihre GitLab CI/CD-Pipeline YAML, um Ihre Build-Umgebung GitLab zu konfigurieren. Ein detaillierteres Verfahren finden Sie unter. [Tutorial: Einen CodeBuild -gehosteten Runner GitLab konfigurieren](sample-gitlab-runners.md) Mit dieser Funktion können Ihre GitLab CI/CD-Pipeline-Jobs nativ integriert werden AWS, was durch Funktionen wie IAM und Amazon VPC Sicherheit und Komfort bietet. AWS CloudTrail Sie können auf die neuesten Instance-Typen zugreifen, einschließlich ARM-basierter Instances. **Topics** + [Über den -hosted CodeBuild Runner GitLab](gitlab-runner-questions.md) + [Tutorial: Einen CodeBuild -gehosteten Runner GitLab konfigurieren](sample-gitlab-runners.md) + [Label-Overrides werden mit dem CodeBuild GitLab -hosted Runner unterstützt](gitlab-runners-update-labels.md) + [Compute Images, die mit dem -hosted Runner unterstützt werden CodeBuild GitLab](sample-gitlab-runners-gitlab-ci.images.md) # Über den -hosted CodeBuild Runner GitLab Im Folgenden finden Sie einige häufig gestellte Fragen zum CodeBuild -hosted Runner GitLab. ## Welche Quelltypen werden für CodeBuild -hosted GitLab runners unterstützt? CodeBuild-gehostete GitLab Runner werden für den `GITLAB_SELF_MANAGED` Quelltyp `GITLAB` und unterstützt. ## Wann sollte ich die Bild- und Instanzüberschreibungen in das Label aufnehmen? Sie können die Image- und Instanzüberschreibungen in das Label aufnehmen, um für jeden Ihrer GitLab CI/CD-Pipeline-Jobs eine andere Build-Umgebung anzugeben. Dies ist möglich, ohne dass mehrere CodeBuild Projekte oder Webhooks erstellt werden müssen. ## Kann ich diese Funktion verwenden CloudFormation ? Ja, Sie können eine Filtergruppe in Ihre CloudFormation Vorlage aufnehmen, die einen GitLab Workflow-Job-Event-Filter in Ihrem Projekt-Webhook spezifiziert. ``` Triggers: Webhook: true FilterGroups: - - Type: EVENT Pattern: WORKFLOW_JOB_QUEUED ``` Weitere Informationen finden Sie unter [GitLab Webhook-Ereignisse filtern ()CloudFormation](gitlab-webhook-events-cfn.md). Wenn Sie Hilfe beim Einrichten von Projektanmeldedaten in Ihrer CloudFormation Vorlage benötigen, finden Sie weitere Informationen [AWS::CodeBuild::SourceCredential](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-sourcecredential.html)im *AWS CloudFormation Benutzerhandbuch*. ## Wie kann ich Geheimnisse maskieren, wenn ich diese Funktion verwende? Standardmäßig werden Geheimnisse, die im Protokoll gedruckt werden, nicht maskiert. Wenn Sie Ihre Geheimnisse maskieren möchten, können Sie dies tun, indem Sie Ihre CI/CD Umgebungsvariableneinstellungen aktualisieren: **Um Geheimnisse zu maskieren in GitLab** 1. Wählen Sie in Ihren **GitLab Einstellungen** **CI/CD**. 1. Wählen Sie unter **Variablen** die Option **Bearbeiten** für das Geheimnis, das Sie maskieren möchten. 1. Wählen Sie unter **Sichtbarkeit** die Option **Maskenvariable** und dann **Variable aktualisieren** aus, um Ihre Änderungen zu speichern. ## Kann ich GitLab Webhook-Ereignisse von mehreren Projekten innerhalb einer einzigen Gruppe erhalten? CodeBuild unterstützt Gruppen-Webhooks, die Ereignisse von einer bestimmten GitLab Gruppe empfangen. Weitere Informationen finden Sie unter [GitLab Gruppen-Webhooks](gitlab-group-webhook.md). ## Kann ich einen Job im Docker Executor für den selbstverwalteten Runner ausführen? Ich möchte beispielsweise einen Pipeline-Job auf einem bestimmten Image ausführen, um dieselbe Build-Umgebung in einem separaten und isolierten Container aufrechtzuerhalten. Sie können den GitLab selbstverwalteten Runner CodeBuild mit einem bestimmten Image ausführen, indem Sie [das Projekt mit einem benutzerdefinierten Image erstellen](create-project.md#environment-image.console) oder [das Image in Ihrer `.gitlab-ci.yml` Datei überschreiben](sample-gitlab-runners.md#sample-gitlab-runners-gitlab-ci). ## Mit welchem Executor läuft der selbstverwaltete Runner? CodeBuild Der selbstverwaltete Runner-In CodeBuild wird mit dem Shell-Executor ausgeführt, wobei der Build lokal zusammen mit dem GitLab Runner ausgeführt wird, der im Docker-Container ausgeführt wird. ## Kann ich Buildspec-Befehle zusammen mit dem selbstverwalteten Runner bereitstellen? Ja, es ist möglich, Buildspec-Befehle zusammen mit dem selbstverwalteten Runner hinzuzufügen. **Sie können die Datei buildspec.yml in Ihrem GitLab Repository bereitstellen und das Tag im Abschnitt „Tags“ des `buildspec-override:true` Jobs verwenden.** Weitere Informationen finden Sie unter [Dateiname der Build-Spezifikation und Speicherort](build-spec-ref.md#build-spec-ref-name-storage). ## In welchen Regionen wird die Verwendung eines -gehosteten Runners unterstützt? CodeBuild GitLab CodeBuild-gehostete GitLab Läufer werden in allen CodeBuild Regionen unterstützt. Weitere Informationen darüber, AWS-Regionen wo CodeBuild es verfügbar ist, findest du unter [AWS Dienste nach Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). ## Welche Plattformen unterstützen die Verwendung eines CodeBuild -gehosteten GitLab Runners? CodeBuild-gehostete GitLab Runner werden sowohl auf Amazon EC2 als auch auf Compute unterstützt. [AWS Lambda](lambda.md) Sie können die folgenden Plattformen verwenden: Amazon Linux 2, Amazon Linux 2023, Ubuntu und Windows Server Core 2019. Weitere Informationen erhalten Sie unter [EC2: Bilder berechnen](ec2-compute-images.md) und [Lambda-Computing-Bilder](lambda-compute-images.md). # Tutorial: Einen CodeBuild -gehosteten Runner GitLab konfigurieren 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 von GitLab oder zur GitLab Selbstverwaltung mit finden Sie CodeBuild unter. [Selbstverwaltete Läufer GitLab in AWS CodeBuild](gitlab-runner.md) Um dieses Tutorial abzuschließen, müssen Sie zunächst: + Stellen Sie eine Connect mit einer OAuth App her, indem Sie CodeConnections Beachten Sie, dass Sie beim Herstellen einer Verbindung mit einer OAuth App die CodeBuild Konsole verwenden müssen. Weitere Anweisungen finden Sie unter [GitLab Zugriff in CodeBuild](access-tokens-gitlab-overview.md). + Connect 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 in CodeBuild](access-tokens-gitlab-overview.md). **Anmerkung** Dies ist nur erforderlich, wenn Sie noch keine Verbindung GitLab zu Ihrem Konto 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 CodeConnections für ein bestimmtes GitLab Konto bereits solche vorhanden sind, werden nicht automatisch Aktualisierungen der Berechtigungen 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. Damit können alle vorhandenen Verbindungen die Runner-Funktion nutzen. Sobald der Vorgang abgeschlossen ist, 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](https://console.aws.amazon.com/codesuite/codebuild/home). 1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md). **Wählen Sie unter **Projekttyp** die Option Runner-Projekt aus.** + In **Runner**: + Wählen Sie für den **Runner-Anbieter** die Option **GitLab**. + Wählen Sie für **Credential** eine der folgenden Optionen aus: + Wählen Sie **Standard-Quellanmeldedaten aus.** Standardverbindung wendet eine GitLab Standardverbindung für alle Projekte an. + Wählen Sie **Benutzerdefinierte Quellanmeldedaten.** Benutzerdefinierte Verbindung wendet eine benutzerdefinierte GitLab Verbindung an, die die Standardeinstellungen Ihres Kontos überschreibt. **Anmerkung** Wenn Sie noch keine Verbindung zu Ihrem Anbieter hergestellt haben, müssen Sie eine neue GitLab Verbindung erstellen. Detaillierte Anweisungen finden Sie unter [Connect CodeBuild GitLab](access-tokens-gitlab-overview.md#connections-gitlab). + Wählen Sie als **Standort für Runner** die Option **Repository** aus. + Wählen Sie für **Repository** den Namen Ihres Projekts aus, GitLab indem Sie den Projektpfad mit dem Namespace angeben. + In **Environment** (Umgebung): + Wählen Sie ein unterstütztes **Umgebungs-Image** und **Compute** aus. Beachten Sie, dass Sie die Möglichkeit haben, die Image- und Instanzeinstellungen zu überschreiben, indem Sie ein Label in Ihrer GitLab CI/CD-Pipeline YAML verwenden. Weitere Informationen finden Sie unter [Schritt 2: Erstellen Sie eine .gitlab-ci.yml-Datei in Ihrem Repository](#sample-gitlab-runners-gitlab-ci). + In **Buildspec (Build-Spezifikation)**: + Beachten Sie, dass Ihre Buildspec ignoriert wird, sofern `buildspec-override:true` sie nicht als Label hinzugefügt wird. Stattdessen überschreibt sie sie, CodeBuild um Befehle zu verwenden, die den selbstverwalteten Runner einrichten. 1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**. 1. Ö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, um Ihre Build-Umgebung [https://gitlab.com/](https://gitlab.com/)zu konfigurieren und selbstverwaltete Runner darin zu verwenden. GitLab CodeBuild Weitere Informationen finden Sie unter [Verwenden von selbstverwalteten Runnern](https://docs.gitlab.com/runner/#use-self-managed-runners). ### Aktualisieren Sie Ihre GitLab CI/CD-Pipeline YAML Navigieren Sie zu Ihrem `https://gitlab.com/user-name/project-name/-/tree/branch-name` Repository und erstellen Sie eine `.gitlab-ci.yml` Datei darin. 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 Rechenleistung, Image, Image-Version und 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 können Jobs mit den richtigen Projekteinstellungen aufgerufen werden. CodeBuild ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME ``` `$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`ist erforderlich, um den Build bestimmten Pipeline-Jobausführungen zuzuordnen und den Build zu beenden, wenn der Pipeline-Lauf abgebrochen wird. **Anmerkung** Stellen Sie sicher, dass Ihr Name ** mit dem Namen des Projekts übereinstimmt, in dem Sie es erstellt haben CodeBuild. Wenn es nicht übereinstimmt, CodeBuild wird der Webhook nicht verarbeitet und die GitLab CI/CD-Pipeline kann hängen bleiben. 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 und Ihren Berechnungstyp im Tag überschreiben. Eine Liste der kuratierten Bilder finden Sie unter[Compute Images, die mit dem -hosted Runner unterstützt werden CodeBuild GitLab](sample-gitlab-runners-gitlab-ci.images.md). Informationen zur Verwendung von benutzerdefinierten Bildern finden Sie unter[Label-Overrides werden mit dem CodeBuild GitLab -hosted Runner unterstützt](gitlab-runners-update-labels.md). 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 EC2-Compute-Build zu überschreiben: ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:- - 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 Ihrem 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](fleets.md). Verwenden Sie die folgende Syntax, um Ihre Flotteneinstellungen für einen Amazon EC2 EC2-Compute-Build zu überschreiben: ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet: ``` Verwenden Sie die folgende Syntax, um sowohl die Flotte als auch das für den Build verwendete Image zu überschreiben: ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet: - image:- ``` Im Folgenden finden Sie 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 in Ihrem CodeBuild Projekt ein benutzerdefiniertes Image konfigurieren und die Angabe eines Image-Override-Labels vermeiden. CodeBuild verwendet das im Projekt konfigurierte Image, wenn kein Image-Override-Label angegeben ist. Nachdem Sie Ihre Änderungen übernommen haben`.gitlab-ci.yml`, wird eine GitLab Pipeline ausgelöst, die `build-job` eine Webhook-Benachrichtigung sendet, mit der Ihr Build gestartet wird. CodeBuild ### Führen Sie die Buildspec-Befehle in den Phasen INSTALL, PRE\$1BUILD und POST\$1BUILD 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, `buildspec-override:true` kann Folgendes als Suffix hinzugefügt werden: `tags` ``` tags: - codebuild--$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-Überschreibung 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är- oder Sekundärquellen herunter. `DOWNLOAD_SOURCE` Wenn Sie eine Buildspec-Datei konfiguriert haben, wird nur diese Datei von der Primärquelle des Projekts heruntergeladen. + Wenn ein Build-Befehl in der `PRE_BUILD` `INSTALL` Oder-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 Ihre `PRE_BUILD` `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 Wann immer ein 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 Pipeline-Job. 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 dann den spezifischen **Job** aus, für den Sie die Logs überprüfen möchten. Sie können die angeforderten Labels im Protokoll überprüfen, während der Job darauf wartet, von einem selbst verwalteten Runner übernommen zu werden. CodeBuild ## GitLab Webhook-Ereignisse filtern ()CloudFormation Der folgende Teil einer CloudFormation Vorlage im YAML-Format erstellt eine Filtergruppe, die einen Build auslöst, wenn sie als wahr ausgewertet wird. Die folgende Filtergruppe gibt einen GitLab CI/CD pipeline job request with a CI/CD Pipeline-Namen an, der dem regulären Ausdruck entspricht. `\[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\] ``` # Label-Overrides werden mit dem CodeBuild GitLab -hosted Runner unterstützt In Ihrer GitLab CI/CD-Pipeline YAML können Sie eine Vielzahl von Label-Overrides bereitstellen, die Ihren selbstverwalteten Runner-Build modifizieren. Alle Builds, die von nicht erkannt werden, CodeBuild werden ignoriert, aber Ihre Webhook-Anfrage wird nicht fehlschlagen. Das folgende YAML beinhaltet beispielsweise Überschreibungen für Image, Instance-Größe, Flotte und Buildspec: ``` 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` (Erforderlich) + Beispiel: `codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME` + Für alle CI/CD-Pipelines erforderlich. GitLab YAMLs **sollte dem Namen des Projekts entsprechen, für das der selbstverwaltete Runner-Webhook konfiguriert ist. `image:-` + Beispiel: `image:arm-3.0` + Setzt das Image und den Umgebungstyp außer Kraft, die beim Starten des selbstverwalteten Runner-Builds verwendet wurden. Weitere Informationen zu unterstützten Werten finden Sie unter. [Compute Images, die mit dem -hosted Runner unterstützt werden CodeBuild GitLab](sample-gitlab-runners-gitlab-ci.images.md) + Um das Bild und den Umgebungstyp, die mit einem benutzerdefinierten Image verwendet werden, zu überschreiben, verwenden Sie `image:custom--` + Beispiel: `image:custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0` **Anmerkung** Wenn sich das benutzerdefinierte Image in einer privaten Registrierung befindet, finden Sie weitere Informationen unter[Konfigurieren Sie private Registrierungsdaten für selbst gehostete Runner](private-registry-sample-configure-runners.md). `instance-size:` + Beispiel: `instance-size:small` + Setzt den Instanztyp außer Kraft, der beim Starten des selbstverwalteten Runner-Builds verwendet wurde. Weitere Informationen zu unterstützten Werten finden Sie unter. [Compute Images, die mit dem -hosted Runner unterstützt werden CodeBuild GitLab](sample-gitlab-runners-gitlab-ci.images.md) `fleet:` + Beispiel: `fleet:myFleet` + Überschreibt die in Ihrem Projekt konfigurierten Flotteneinstellungen, um die angegebene Flotte zu verwenden. Weitere Informationen finden Sie unter [Führen Sie Builds auf Flotten mit reservierter Kapazität aus](fleets.md). `buildspec-override:` + Beispiel: `buildspec-override:true` + Ermöglicht dem Build die Ausführung von Buildspec-Befehlen in den `POST_BUILD` Phasen, und `INSTALL``PRE_BUILD`, sofern auf gesetzt. `true` # Compute Images, die mit dem -hosted Runner unterstützt werden CodeBuild GitLab In dem Label[Tutorial: Einen CodeBuild -gehosteten Runner GitLab konfigurieren](sample-gitlab-runners.md), in dem Sie konfiguriert haben, können Sie Ihre Amazon EC2 EC2-Umgebungseinstellungen überschreiben, indem Sie die Werte in den ersten drei Spalten verwenden. CodeBuild stellt die folgenden Amazon EC2 EC2-Compute-Images bereit. Weitere Informationen zur [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html) Darüber hinaus können Sie Ihre Lambda-Umgebungseinstellungen überschreiben, indem Sie die folgenden Werte verwenden. Weitere Hinweise zu CodeBuild Lambda Compute finden Sie unter[Builds auf dem AWS Lambda Computer ausführen](lambda.md). CodeBuild unterstützt die folgenden Lambda-Compute-Images: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html) Weitere Informationen erhalten Sie unter [Berechnungsmodi und Typen der Build-Umgebung](build-env-ref-compute-types.md) und [Docker-Images bereitgestellt von CodeBuild](build-env-ref-available.md).