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
Themen
- Wie fange ich an, eine GitHub Aktion in meiner Buildspec zu verwenden?
- Welche GitHub Aktionen kann ich in meiner Buildspec verwenden?
- Kann ich andere Quellanbieter verwenden als GitHub wenn ich GitHub Actions in meiner Buildspec verwende?
- Warum muss ich eine Verbindung GitHub als Quellanbieter herstellen, um GitHub Actions in meiner Buildspec verwenden zu können?
- Wie viel kostet es, GitHub Aktionen in meiner Buildspec zu verwenden?
- Welche Regionen unterstützen die Verwendung von GitHub Aktionen in meiner Buildspec?
- Bewährte Methoden für die Verwendung von GitHub Aktionen in Ihrer Buildspec
- Einschränkungen bei der Verwendung von GitHub Aktionen in Ihrer Buildspec in CodeBuild
- GitHub Action-Runner-Buildspec-Referenz
- GitHub Syntaxbeispiele für Aktionen mit AWS 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:
-
Falls Sie dies noch nicht getan haben, verbinden Sie Ihr Projekt mit. GitHub
Dazu können Sie einen der folgenden Schritte ausführen:
-
Sie können in GitHub der Konsole einen Quellanbieter hinzufügen. Weitere Informationen finden Sie unter GitHub Mit einem Zugriffstoken (Konsole) Connect .
-
Sie können Ihre GitHub Anmeldeinformationen über die CodeBuild API importieren. Weitere Informationen finden Sie unter GitHub Mit einem Zugriffstoken (CLI) Connect .
Anmerkung
Dies muss nur geschehen, wenn Sie noch keine Verbindung zu GitHub einem anderen Projekt hergestellt haben.
-
-
In der Buildspec Ihres Projekts können Sie hinzufügen
steps
, 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
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
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
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
github
Kontextangewiesen 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 Marketplaceverfü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. -
Aktionen müssen als Root-Benutzer ausgeführt werden. Weitere Informationen finden Sie im Thema USER
unter Dockerfile-Unterstützung für GitHub Aktionen .
-
-
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 festlegen
with
. 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 mitrun
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 Sie
shell
.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:
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
Themen
Beispiel Super-Linter Action GitHub
Dieses Beispiel zeigt, wie die GitHub Super-Linter-Aktion
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