View a markdown version of this page

Label-Overrides werden vom Actions-Runner unterstützt CodeBuild-hosted GitHub - AWS CodeBuild
Überschreibung einzelner Bezeichnungen

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.

Label-Overrides werden vom Actions-Runner unterstützt CodeBuild-hosted GitHub

In Ihrem GitHub Aktions-Workflow-YAML können Sie eine Vielzahl von Label-Overrides bereitstellen, die Ihren selbst gehosteten Runner-Build modifizieren. Alle Builds, die von nicht erkannt werden, CodeBuild werden ignoriert, aber Ihre Webhook-Anfrage wird nicht fehlschlagen. Der folgende Workflow-YAML definiert zwei Jobs: job1 verwendet Overrides für Image, Instance-Größe, Flotte und Buildspec und verwendet nur eine Image-Override. job2 Geben Sie jedem Job eine eindeutige Bezeichnung (job1undjob2), sodass jeder Job an den GitHub dafür erstellten Runner weitergeleitet wird:

name: Hello World
on: [push]
jobs:
  job1:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - image:arm-3.0
      - instance-size:small
      - fleet:myFleet
      - buildspec-override:true
      - job1
    steps:
      - run: echo "Hello from Job 1!"
  job2:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - image:linux-5.0
      - job2
    steps:
      - run: echo "Hello from Job 2!"

Sie können auch eine Matrixstrategie verwenden, um einen einzelnen Job in mehreren Konfigurationen auszuführen. Die Erweiterungen eines einzelnen Matrix-Jobs haben immer dieselbe Anzahl von Labels, sodass das Runner-Matching-Problem sie nicht beeinträchtigt. Wenn ein Workflow-Lauf jedoch mehr als einen Matrix-Job enthält, geben Sie jedem Matrix-Job eine eigene benutzerdefinierte Bezeichnung (z. B. matrix-job-1 undmatrix-job-2), sodass ein Job GitHub nicht einem Runner zugeordnet wird, der für einen anderen Matrix-Job erstellt wurde:

name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - image:${{ matrix.os }}
      - instance-size:${{ matrix.size }}
      - fleet:myFleet
      - buildspec-override:true
      - matrix-job-1
    strategy:
      matrix:
        include:
          - os: arm-3.0
            size: small
          - os: linux-5.0
            size: large
    steps:
      - run: echo "Hello World!"
Anmerkung

Wenn Ihr Workflow-Job nicht weiterläuft GitHub, finden Sie weitere Informationen unter Beheben Sie Probleme mit dem Webhook und Verwenden von benutzerdefinierten Labels zur Weiterleitung von Aufträgen.

codebuild-<project-name>-${{github.run_id}}-${{github.run_attempt}} (Erforderlich)

  • Beispiel: codebuild-fake-project-${{ github.run_id }}-${{ github.run_attempt }}

  • Erforderlich für alle GitHub Aktions-Workflow-YAMLs. <project name>sollte dem Namen des Projekts entsprechen, für das der selbst gehostete Runner-Webhook konfiguriert ist.

image:<environment-type>-<image-identifier>

  • Beispiel: image:arm-3.0

  • Überschreibt das Image und den Umgebungstyp, die verwendet werden, wenn der selbst gehostete Runner-Build mit einem kuratierten Image gestartet wird. Weitere Informationen zu unterstützten Werten finden Sie unter. Bilder berechnen, die vom Actions-Runner unterstützt CodeBuild-hosted GitHub werden

    • Um das Bild und den Umgebungstyp, die mit einem benutzerdefinierten Image verwendet werden, zu überschreiben, verwenden Sie image:custom-<environment-type>-<custom-image-identifier>

    • 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 unterKonfigurieren Sie private Registrierungsdaten für selbst gehostete Runner.

instance-size:<instance-size>

fleet:<fleet-name>

buildspec-override:<boolean>

  • Beispiel: buildspec-override:true

  • Ermöglicht dem Build die Ausführung von Buildspec-Befehlen in den POST_BUILD Phasen, und INSTALLPRE_BUILD, sofern auf gesetzt. true

<unique-label>(empfohlen, wenn ein Workflow-Lauf mehrere Jobs umfasst)

  • Beispiel: job1

  • Ein benutzerdefiniertes Label, das Sie definieren und das kein anderer Job in derselben Workflow-Ausführung verwendet. Wenn Sie jedem Job eine eindeutige Bezeichnung zuweisen, wird sichergestellt, dass GitHub jeder Job nur an den Runner weitergeleitet wird, der für ihn erstellt wurde. Wenn Jobs in derselben Workflow-Ausführung eine unterschiedliche Anzahl von Label-Überschreibungen aufweisen, kann ein Job mit weniger Labels von einem Runner übernommen werden, der für einen Job mit mehr Labels erstellt wurde, sodass der zweite Job keinen Runner hat. Weitere Informationen finden Sie unter Beheben Sie Probleme mit dem Webhook.

Überschreibung einzelner Bezeichnungen

CodeBuild ermöglicht es Ihnen, mehrere Überschreibungen in einem einzigen Label bereitzustellen, indem Sie Folgendes verwenden:

Anmerkung

Da alle Überschreibungen in einem einzigen Label zusammengefasst sind, registriert sich der Runner jedes Jobs mit genau einem Label. Das bedeutet, dass das unter beschriebene Problem beim Abgleich mehrerer Jobs bei diesem Format Beheben Sie Probleme mit dem Webhook nicht auftreten kann, auch wenn für jeden Job keine eindeutige Bezeichnung vorhanden ist. Verwenden Sie das Single-Label-Format, wenn Sie dieses Verhalten bevorzugen und Ihre Jobs nur Überschreibungen benötigen, die es unterstützt. Verwenden Sie es nicht, wenn Sie eine Überschreibung benötigen, die es nicht unterstützt. Beispielsweise können benutzerdefinierte Bilder (einschließlich Bilder in einer privaten Registrierung) nur mithilfe des image:custom-<environment-type>-<custom-image-identifier> Labelformats angegeben werden. Verwenden Sie für diese Überschreibungen das weiter oben in diesem Thema beschriebene separate Labelformat.

  • Verwenden Sie die folgende Syntax, um Ihre Umgebungseinstellungen für einen EC2/Lambda Amazon-Compute-Build zu überschreiben:

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<environment-type>-<image-identifier>-<instance-size>

  • Verwenden Sie die folgende Syntax, um Ihre Flotteneinstellungen für Amazon EC2 Compute Build zu überschreiben:

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-fleet-<fleet-name>

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

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-image-<image-version>-fleet-<fleet-name>

  • Um Buildspec-Befehle während des Builds auszuführen, -with-buildspec können dem Label als Suffix hinzugefügt werden:

    runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<image>-<image-version>-<instance-size>-with-buildspec

  • Optional können Sie eine Überschreibung der Instanzgröße angeben, ohne das Image zu überschreiben. Für Amazon EC2 EC2-Builds können Sie sowohl den Umgebungstyp als auch die Image-ID ausschließen. Bei Lambda-Builds können Sie die Image-ID ausschließen.