Verwenden Sie die GitHub Aktionssyntax in einer Buildspec in AWS CodeBuild - AWS CodeBuild

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.

Verwenden Sie die GitHub Aktionssyntax in einer Buildspec in AWS CodeBuild

Sie können einen von CodeBuild -managed Action Runner verwenden, um darin Aktionen auszuführen. GitHub CodeBuild Dies kann durch Hinzufügen steps zu einer beliebigen Phase in Ihrer Buildspec-Datei geschehen.

CodeBuild Buildspecs unterstützen eine Liste sequentieller GitHub Aktionsschritte, die in einer von Befehlen getrennten Phase ausgeführt werden. CodeBuild Diese GitHub Aktionen lassen sich in die vorhandenen Funktionen integrieren, zu denen das Zwischenspeichern von Abhängigkeiten, Batch-Builds, Zugriff AWS Secrets Manager auf und mehr gehören. CodeBuild

Wie fange ich an, eine GitHub Aktion in meiner Buildspec zu verwenden?

Die wichtigsten Schritte zur Verwendung einer GitHub Aktion in Ihrer Buildspec lauten wie folgt:

  1. Falls Sie dies noch nicht getan haben, verbinden Sie Ihr Projekt mit. GitHub

    Dazu können Sie einen der folgenden Schritte ausführen:

    Anmerkung

    Dies muss nur geschehen, wenn Sie noch keine Verbindung zu GitHub einem anderen Projekt hergestellt haben.

  2. In der Buildspec Ihres Projekts können Sie hinzufügensteps, von denen jede auf eine Aktion verweist. GitHub Dies kann in der CodeBuild Konsole oder in Ihrem Quell-Repository bearbeitet werden. Jede Buildphase unterstützt entweder eine Liste von Befehlen oder eine Liste von Schritten, aber beide können nicht in derselben Phase verwendet werden. Weitere Informationen finden Sie unter Verwenden Sie die GitHub Aktionssyntax in einer Buildspec in AWS CodeBuild.

Welche GitHub Aktionen kann ich in meiner Buildspec verwenden?

Sie können jede auf dem GitHub Marketplace verfügbare Aktion verwenden, die nicht mit diesen Einschränkungen kollidiert.

Kann ich andere Quellanbieter verwenden als GitHub wenn ich GitHub Actions in meiner Buildspec verwende?

Ja, aber es GitHub ist immer noch eine Verbindung zu erforderlich, um sich mit GitHub Aktionen zu authentifizieren und darauf zuzugreifen. GitHub Weitere Informationen finden Sie unter GitHub und GitHub Enterprise Server-Zugriffstoken.

Warum muss ich eine Verbindung GitHub als Quellanbieter herstellen, um GitHub Actions in meiner Buildspec verwenden zu können?

Um GitHub Actions in Ihrer Buildspec verwenden zu können, muss die Quelle auf einen Build-Computer heruntergeladen werden. Anonyme Downloads sind ratenbegrenzt. Wenn Sie also eine Verbindung herstellen, kann dies dazu beitragen GitHub, einen konsistenten Zugriff zu gewährleisten.

Wie viel kostet es, GitHub Aktionen in meiner Buildspec zu verwenden?

Die Verwendung von GitHub Aktionen in Ihrer Buildspec wird ohne zusätzliche Kosten unterstützt.

Welche Regionen unterstützen die Verwendung von GitHub Aktionen in meiner Buildspec?

Die Verwendung von GitHub Aktionen in Ihrer Buildspec wird in allen Regionen unterstützt. CodeBuild Weitere Informationen darüber, AWS-Regionen wo verfügbar CodeBuild ist, finden Sie unter AWS Dienste nach Regionen.

Bewährte Methoden für die Verwendung von GitHub Aktionen in Ihrer Buildspec

GitHub Aktionen sind Open Source und werden von der Community erstellt und verwaltet. Wir folgen dem Modell der gemeinsamen Verantwortung und betrachten den Quellcode von GitHub Actions als Kundendaten, für die Sie verantwortlich sind. GitHub Aktionen können Zugriff auf Geheimnisse, Repository-Token, Quellcode und Konto-Links gewährt werden. Stellen Sie sicher, dass Sie von der Vertrauenswürdigkeit und Sicherheit der GitHub Aktionen, die Sie ausführen möchten, überzeugt sind.

Spezifischere Leitlinien und bewährte Sicherheitsverfahren für GitHub Aktionen:

Einschränkungen bei der Verwendung von GitHub Aktionen in Ihrer Buildspec in CodeBuild

  • GitHub Aktionen in Ihrer Buildspec, die intern auf den githubKontext angewiesen sind oder auf GitHub spezifische Ressourcen verweisen, wie Pull-Requests und Issues, werden in nicht unterstützt. CodeBuild Die folgenden Aktionen funktionieren beispielsweise nicht in: CodeBuild

    • GitHub Aktionen, mit denen versucht wird, GitHub Ressourcen hinzuzufügen, zu ändern oder zu aktualisieren, z. B. Aktionen, die Pull-Requests aktualisieren oder Probleme in verursachen GitHub.

    Anmerkung

    Die meisten offiziellen GitHub Aktionen, die unter https://github.com/actions aufgeführt sind, hängen vom github Kontext ab. Verwenden Sie stattdessen die im GitHub Marketplace verfügbaren Aktionen.

  • GitHub Aktionen in Ihrer Buildspec, bei denen es sich um Docker-Container-Aktionen handelt, funktionieren, aber für Ihr Build-Projekt muss der privilegierte Modus aktiviert sein und vom Standard-Docker-Benutzer (root) ausgeführt werden.

  • GitHub Aktionen in Ihrer Buildspec werden in CodeBuild Projekten, die für die Ausführung unter Windows konfiguriert sind, nicht unterstützt.

  • GitHub Aktionsaufträge (Gruppen von Schritten) und Eigenschaften von GitHub Aktionsaufträgen in Ihrer Buildspezifikation werden nicht unterstützt.

  • GitHub Aktionen in Ihrer Buildspec werden in CodeBuild Projekten nicht unterstützt, die so konfiguriert sind, dass sie durch einen Webhook für ein öffentliches Git-Repository ausgelöst werden. Weitere Informationen finden Sie unter. git-credential-helper

  • VPC-Builds ohne öffentlichen Internetzugang können keine GitHub Aktionen in Ihrer Buildspec ausführen.

  • Jede Buildphase unterstützt entweder eine Liste von Befehlen oder eine Liste von Schritten, aber beide können nicht in derselben Phase verwendet werden. Im folgenden Beispiel werden Schritte in der Phase vor der Erstellung zum Auflisten von GitHub Aktionen verwendet, während Befehle in der Erstellungsphase zum Auflisten von CodeBuild Befehlen verwendet werden.

    version: 0.2 phases: pre-build: steps: - name: Lint Code Base uses: github/super-linter@v4 env: VALIDATE_ALL_CODEBASE: 'true' DEFAULT_BRANCH: main build: commands: - echo "Building..." - npm run build

GitHub Action-Runner-Buildspec-Referenz

Dieses Thema enthält die Buildspec-Referenz für Action-Runner-Eigenschaften. GitHub

steps

Optionale Sequenz. Schritte werden verwendet, um Befehle und Aktionen in auszuführen. CodeBuild Weitere Informationen finden Sie unter Verwenden Sie die GitHub Aktionssyntax in einer Buildspec in AWS CodeBuild.

Anmerkung

Jede Buildphase unterstützt entweder eine Liste von commands oder eine Liste vonsteps, aber beide können nicht in derselben Phase verwendet werden.

Jeder Build-Schritt enthält die folgenden Eigenschaften.

id

Optional. Der Bezeichner für den Schritt, der verwendet werden kann, um in anderen Kontexten auf den Schritt zu verweisen.

if

Optional. Eine bedingte Anweisung, die verwendet werden kann, um zu verhindern, dass ein Schritt ausgeführt wird, sofern keine Bedingung erfüllt ist. Diese Anweisung kann jeden unterstützten Kontext verwenden, z. B. den Verweis auf Umgebungsvariablen von CodeBuild oder einen Ausdruck.

Name

Optional. Der Name für den Schritt. Wenn der Name nicht angegeben ist, wird als Name standardmäßig der im run Befehl angegebene Text verwendet.

verwendet

Die Aktion, die für den Schritt ausgeführt wird. Bei einigen Aktionen müssen Sie Eingaben mithilfe von festlegenwith. In der README-Datei der Aktion finden Sie Informationen darüber, welche Eingaben erforderlich sind. Weitere Informationen finden Sie unter Welche GitHub Aktionen kann ich in meiner Buildspec verwenden?.

Wenn in Ihrer Erstellungsphase angegeben uses ist, kann es nicht mit run verwendet werden.

Anmerkung

Es wird empfohlen, dass Sie die Version der Aktion angeben, die Sie verwenden. Dies kann durch Angabe eines Git-Ref-, SHA- oder Docker-Tags erfolgen. Weitere Informationen finden Sie unter steps.uses Syntax.

ausführen

Ein Befehl, der Befehlszeilenprogramme ausführt. Dies können einzeilige Befehle oder mehrzeilige Befehle sein. Standardmäßig werden diese Befehle mit Shells ausgeführt, bei denen keine Anmeldung erforderlich ist. Um eine andere Shell auszuwählen, verwenden Sieshell.

Wenn in Ihrer Buildphase angegeben run ist, kann es nicht mit verwendet werdenuses.

Schale

Optional. Die für diese Sequenz angegebene Shell. Informationen zu unterstützten Shell-Parametern finden Sie unter steps.shell. Falls nicht spezifiziert, wird bash als Shell verwendet. Wenn bash nicht verfügbar ist, wird sh verwendet.

mit

Optional. Eine Karte von Eingabeparametern, die durch die Aktion definiert wurden. Jeder Parameter ist ein Schlüssel/Wert-Paar.

mit.args

Optional. Eine Zeichenfolge, die Eingaben für einen Docker-Container definiert.

mit.entrypoint

Optional. Der für das Dockerfile angegebene Docker-Einstiegspunkt.

env

Optional. Die Variablen, die für Schritte angegeben sind, die in der Umgebung verwendet werden sollen.

continue-on-error

Optional. Ein boolescher Wert, der angibt, ob ein Fehler dieser Schrittsequenz ignoriert werden kann.

false

Der Standardwert. Wenn diese Schrittsequenz fehlschlägt, schlägt der Build fehl.

true

Wenn diese Schrittsequenz fehlschlägt, kann der Build trotzdem erfolgreich sein.

Timeout in Minuten

Optional. Die maximale Anzahl von Minuten, für die der Schritt ausgeführt werden kann, bevor er beendet wird. Standardmäßig gibt es kein Timeout. Wenn das Schritttimeout das Build-Timeout überschreitet, wird der Schritt beendet, wenn das Build-Timeout erreicht ist.

Im Folgenden finden Sie ein Beispiel für die Verwendung der Super-Linter-Aktion: GitHub

version: 0.2 phases: build: steps: - name: Lint Code Base uses: github/super-linter@v5 env: VALIDATE_ALL_CODEBASE: true USE_FIND_ALGORITHM: true FILTER_REGEX_INCLUDE: '/github/workspace/buildspec.yml'

GitHub Syntaxbeispiele für Aktionen mit AWS CodeBuild

Diese Gruppen von Beispielen können verwendet werden, um mit GitHub Aktionen in Ihrer Buildspec in zu experimentieren. CodeBuild

Beispiel Super-Linter Action GitHub

Dieses Beispiel zeigt, wie die GitHub Super-Linter-Aktion zu einem Projekt hinzugefügt wird. CodeBuild Die Super-Linter-Aktion untersucht den Code, findet Bereiche, in denen der Code Fehler, Formatierungsprobleme und verdächtige Konstrukte enthält, und gibt die Ergebnisse dann an der Konsole aus. CodeBuild

Sie können die GitHub Super-Linter-Aktion zu Ihrem CodeBuild Projekt hinzufügen, indem Sie den Phasenabschnitt Ihrer Buildspec-Datei aktualisieren.

version: 0.2 phases: build: steps: - name: Lint Code Base uses: github/super-linter@v5 env: VALIDATE_ALL_CODEBASE: true

Die Super-Linter-Protokolle werden etwa wie folgt aussehen:

/github/workspace/hello-world/app.js:3:13: Extra semicolon. /github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed. /github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found. /github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4. /github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.

Beispiel für eine Batch-Erstellung eines Diagramms

Das folgende Beispiel definiert ein Build-Diagramm, das eine Abhängigkeitskette erstellt und Befehle mithilfe von ausführtsteps. In diesem Beispiel wird es zuerst build1 ausgeführt, da es keine Abhängigkeiten hat. Da von abhängig build2 ist, build2 wird also ausgeführtbuild1, nachdem Build1 abgeschlossen ist. Weitere Informationen finden Sie unter Diagramm erstellen.

version: 0.2 batch: fast-fail: false build-graph: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 env: variables: BUILD_ID: build2 depend-on: - build1 phases: build: steps: - run: echo $BUILD_ID

Beispiel für Amazon CodeGuru Reviewer

Amazon CodeGuru Reviewer findet Probleme in Ihrem Java- und Python-Code und empfiehlt, wie Sie diese beheben können. Im folgenden Beispiel wird CodeGuru Reviewer verwendet, um vollständige Repository-Analyse-Code-Reviews bereitzustellen. Bei diesen Codeüberprüfungen wird der gesamte Code in einem bestimmten Zweig gescannt. Weitere Informationen finden Sie unter Code-Rezensionen mit GitHub Aktionen erstellen im Amazon CodeGuru Reviewer-Benutzerhandbuch.

version: 0.2 phases: build: steps: - name: Amazon CodeGuru Reviewer Scanner if: ${{ always() }} uses: aws-actions/codeguru-reviewer@v1.1 with: s3_bucket: codeguru-reviewer-user artifacts: files: - codeguru-results.sarif.json
Anmerkung

Ihr Amazon S3 S3-Bucket muss mit dem codeguru-reviewer- Präfix beginnen.

Die Protokolle werden in etwa wie folgt aussehen:

INFO CodeReview created with arn=arn:aws:codeguru-reviewer:region:account-id:association:id:code-review:RepositoryAnalysis-job for job=job INFO SARIF persisted to /github/workspace/codeguru-results.sarif.json INFO Amazon CodeGuru Reviewer job execution completed

Nachdem der Amazon CodeGuru Reviewer-Job abgeschlossen ist, wird ein Sarif-Bericht als CodeBuild Artefakt generiert. Weitere Informationen finden Sie unter Vollständige Repository-Analyse im Amazon CodeGuru Reviewer-Benutzerhandbuch.

AWS Secrets Manager Beispiel

AWS Secrets Manager hilft Ihnen dabei, Datenbankanmeldedaten, Anwendungsanmeldedaten, OAuth-Token, API-Schlüssel und andere Geheimnisse während ihrer gesamten Lebensdauer zu verwalten, abzurufen und zu rotieren. Das folgende Beispiel definiert ein Geheimnis mit Secrets Manager und führt Befehle mit aussteps. Weitere Informationen finden Sie unter Was ist AWS Secrets Manager? im AWS Secrets Manager Benutzerhandbuch.

version: 0.2 env: secrets-manager: SECRET_VALUE: "arn:aws:secretsmanager:us-east-1:xxxx:secret:/secret-l3IJg9:my_super_secret_key" phases: build: steps: - run: echo $SECRET_VALUE

Die Protokolle werden in etwa wie folgt aussehen:

echo $SECRET_VALUE env: SECRET_VALUE: *** ***

Beispiel für eine Umgebungsvariable

Das folgende Beispiel definiert Umgebungsvariablen in der env Sequenz. <bucket-name>Eine S3_BUCKET-Variable ist in der Buildspec definiert und ihr als Wert zugewiesen. Auf diese Variable wird in der if-Bedingung wie auf eine normale Umgebungsvariable verwiesen, indem das Dollarzeichen ($) für den Zugriff auf den Action env-Kontext verwendet wird. GitHub Weitere Informationen finden Sie unter envSequenz.

version: 0.2 env: variables: S3_BUCKET: "<bucket-name>" phases: build: steps: - if: ${{ env.S3_BUCKET == '<bucket-name>' }} run: echo "S3 bucket is $S3_BUCKET"

Die Protokolle werden in etwa wie folgt aussehen:

echo "S3 bucket is $S3_BUCKET" env: S3_BUCKET: my-s3-bucket S3 bucket is my-s3-bucket

Beispiel für eine exportierte Umgebungsvariable

Exportierte Umgebungsvariablen werden in Verbindung mit verwendet CodePipeline , um Umgebungsvariablen aus der aktuellen Erstellungsphase in nachfolgende Phasen der Pipeline zu exportieren. Das folgende Beispiel definiert eine exportierte Umgebungsvariable unter der env Sequenz MY_VARIABLE und schreibt in die GITHUB_ENV-Umgebungsdatei.

version: 0.2 env: exported-variables: - MY_VARIABLE phases: build: steps: - run: echo "MY_VARIABLE=my-value" >> $GITHUB_ENV

Weitere Informationen finden Sie in der API-Referenz. ExportedEnvironmentVariableAWS CodeBuild