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.
Referenz zur Build-Spezifikation für CodeBuild
Dieses Thema stellt wichtige Referenzinformationen über Build-Spezifikationsdateien (buildspecs) bereit. Eine Buildspec ist eine Sammlung von Build-Befehlen und zugehörigen Einstellungen in einem YAML Format, das zur Ausführung eines Builds CodeBuild verwendet wird. Sie können eine Buildspec als Teil des Quellcodes einbeziehen oder Sie können eine Buildspec definieren, wenn Sie ein Build-Projekt erstellen. Informationen zur Funktionsweise einer Build-Spezifikation finden Sie unter Wie CodeBuild funktioniert.
Themen
Dateiname der Build-Spezifikation und Speicherort
Wenn Sie eine Build-Spezifikation als Teil des Quellcodes einbinden, muss die Build-Spezifikationsdatei standardmäßig als buildspec.yml
benannt und im Stammverzeichnis Ihres Quellverzeichnisses abgelegt werden.
Sie können den Standard-Namen und -Speicherort der Build-Spezifikationsdatei überschreiben. Beispielsweise ist Folgendes möglich:
-
Verwenden Sie eine andere Build-Spezifikationsdatei für verschiedene Builds im selben Repository, z. B.
buildspec_debug.yml
undbuildspec_release.yml
. -
Speichern Sie eine Build-Spezifikationsdatei in einem anderen Verzeichnis als dem Stammverzeichnis des Quellverzeichnisses, also z. B. in
config/buildspec.yml
oder in einem S3-Bucket. Der S3-Bucket muss sich in derselben AWS Region wie Ihr Build-Projekt befinden. Geben Sie die Buildspec-Datei mit ihrer an ARN (z. B.).arn:aws:s3:::
<my-codebuild-sample2>
/buildspec.yml
Sie können für ein Build-Projekt nur ein Build-Spezifikation angeben, unabhängig vom Namen der Build-Spezifikationsdatei.
Führen Sie einen der folgenden Schritte aus, um den Standard-Dateinamen, -Speicherort der Build-Spezifikationsdatei oder beides zu überschreiben:
-
Führen Sie den
update-project
Befehl AWS CLIcreate-project
or aus und setzen Sie denbuildspec
Wert auf den Pfad zur alternativen Buildspec-Datei relativ zum Wert der integrierten Umgebungsvariablen.CODEBUILD_SRC_DIR
Sie können das Gleiche auch mit dercreate project
Operation in der tun. AWS SDKs Weitere Informationen finden Sie unter Erstellen eines Build-Projekts oder Ändern der Einstellungen eines Build-Projekts. -
Führen Sie den AWS CLI
start-build
Befehl aus und legen Sie denbuildspecOverride
Wert auf den Pfad zur alternativen Buildspec-Datei relativ zum Wert der integrierten Umgebungsvariablen fest.CODEBUILD_SRC_DIR
Sie können das Gleiche auch mit derstart build
Operation in der tun. AWS SDKs Weitere Informationen finden Sie unter Ausführen eines Build. -
Legen Sie in einer AWS CloudFormation Vorlage die
BuildSpec
Eigenschaft vonSource
in einer Ressource vom TypAWS::CodeBuild::Project
auf den Pfad zur alternativen Buildspec-Datei relativ zum Wert der integrierten Umgebungsvariablen fest.CODEBUILD_SRC_DIR
Weitere Informationen finden Sie unter der BuildSpec Eigenschaft in der AWS CodeBuild Projektquelle im AWS CloudFormation Benutzerhandbuch.
Syntax der Build-Spezifikation
Buildspec-Dateien müssen im Format ausgedrückt werden. YAML
Wenn ein Befehl ein Zeichen oder eine Zeichenfolge enthält, die von nicht unterstützt wird, müssen Sie den Befehl in Anführungszeichen („“) setzen. YAML Der folgende Befehl ist in Anführungszeichen eingeschlossen, da ein Doppelpunkt (:) gefolgt von einem Leerzeichen nicht zulässig ist. YAML Das Anführungszeichen im Befehl wird mit Escape (\") angegeben.
"export PACKAGE_NAME=$(cat package.json | grep name | head -1 | awk -F: '{ print $2 }' | sed 's/[\",]//g')"
Die Build-Spezifikation hat die folgende Syntax:
version: 0.2 run-as:
Linux-user-name
env: shell:shell-tag
variables:key
: "value
"key
: "value
" parameter-store:key
: "value
"key
: "value
" exported-variables: -variable
-variable
secrets-manager:key
:secret-id
:json-key
:version-stage
:version-id
git-credential-helper: no | yes proxy: upload-artifacts: no | yes logs: no | yes batch: fast-fail: false | true # build-list: # build-matrix: # build-graph: phases: install: run-as:Linux-user-name
on-failure: ABORT | CONTINUE runtime-versions:runtime
:version
runtime
:version
commands: -command
-command
finally: -command
-command
pre_build: run-as:Linux-user-name
on-failure: ABORT | CONTINUE commands: -command
-command
finally: -command
-command
build: run-as:Linux-user-name
on-failure: ABORT | CONTINUE commands: -command
-command
finally: -command
-command
post_build: run-as:Linux-user-name
on-failure: ABORT | CONTINUE commands: -command
-command
finally: -command
-command
reports:report-group-name-or-arn
: files: -location
-location
base-directory:location
discard-paths: no | yes file-format:report-format
artifacts: files: -location
-location
name:artifact-name
discard-paths: no | yes base-directory:location
exclude-paths:excluded paths
enable-symlinks: no | yes s3-prefix:prefix
secondary-artifacts:artifactIdentifier
: files: -location
-location
name:secondary-artifact-name
discard-paths: no | yes base-directory:location
artifactIdentifier
: files: -location
-location
discard-paths: no | yes base-directory:location
cache: paths: -path
-path
Die Build-Spezifikation enthält Folgendes:
version
Erforderliche Zuweisung. Diese steht für die Version der Build-Spezifikation. Wir empfehlen Ihnen, 0.2
zu verwenden.
Anmerkung
Obwohl Version 0.1 wird weiterhin unterstützt wird, empfehlen wir Ihnen, nach Möglichkeit Version 0.2 zu verwenden. Weitere Informationen finden Sie unter Versionen der Build-Spezifikationen.
run-as
Optionale Sequenz. Nur für Linux-Benutzer verfügbar. Gibt einen Linux-Benutzer an, der Befehle in dieser Buildspec-Datei ausführt. run-as
gewährt dem angegebenen Benutzer Lese- und Ausführungsberechtigungen. Wenn Sie run-as
zu Beginn der buildspec-Datei angeben, gilt die Einstellung global für alle Befehle. Wenn Sie nicht möchten, dass ein Benutzer Berechtigungen für sämtliche Befehle in der buildspec-Datei erhält, können Sie die Berechtigungen auf eine Phase beschränken, indem Sie run-as
in einem der phases
-Blöcke angeben. Wird run-as
nicht angegeben, werden alle Befehle als Root-Benutzer ausgeführt.
env
Optionale Sequenz. Diese steht für die Informationen von einer oder mehrerer benutzerdefinierter Umgebungsvariablen.
Anmerkung
Um vertrauliche Informationen zu schützen, sind die folgenden Informationen in CodeBuild Protokollen versteckt:
-
AWS ZugriffsschlüsselIDs. Weitere Informationen finden Sie im Benutzerhandbuch unter Verwaltung von Zugriffsschlüsseln für IAM AWS Identity and Access Management Benutzer.
-
Mit dem Parameter Store angegebene Zeichenfolgen. Weitere Informationen finden Sie unter Systems Manager Parameter Store und Systems Manager Parameter Store Console Walkthrough im Amazon EC2 Systems Manager Manager-Benutzerhandbuch.
-
Zeichenketten, die mit angegeben wurden AWS Secrets Manager. Weitere Informationen finden Sie unter Schlüsselverwaltung.
- env/Shell
-
Optionale Sequenz. Gibt die unterstützte Shell für Linux- oder Windows-Betriebssysteme an.
Für Linux-Betriebssysteme werden folgende Shell-Tags unterstützt:
-
bash
-
/bin/sh
Für Windows-Betriebssysteme werden folgende Shell-Tags unterstützt:
-
powershell.exe
-
cmd.exe
-
- env/variables
-
Erforderlich, wenn
env
angegeben ist und Sie benutzerdefinierte Umgebungsvariablen im Klartext definieren möchten. Enthält eine Zuordnung vonkey
/value
Skalare, wobei jede Zuordnung eine einzelne benutzerdefinierte Umgebungsvariable im Klartext darstellt.key
ist der Name der benutzerdefinierten Umgebungsvariablen undvalue
ist der Wert dieser Variablen.Wichtig
Wir raten dringend davon ab, sensible Werte in Umgebungsvariablen zu speichern. Umgebungsvariablen können mit Tools wie der CodeBuild Konsole und dem im Klartext angezeigt werden. AWS CLI Für vertrauliche Werte sollte stattdessen die Zuweisung per
parameter-store
odersecrets-manager
verwendet werden (siehe unten in diesem Abschnitt).Jede festgelegte Umgebungsvariable ersetzt vorhandene Umgebungsvariablen. Wenn das Docker-Image beispielsweise bereits eine Umgebungsvariable mit dem Namen
MY_VAR
und einem Wert vonmy_value
enthält und Sie eine Umgebungsvariable mit dem NamenMY_VAR
und einem Wert vonother_value
festlegen, wirdmy_value
durchother_value
ersetzt. Wenn das Docker-Image demgegenüber bereits eine Umgebungsvariable mit dem NamenPATH
und einem Wert von/usr/local/sbin:/usr/local/bin
enthält und Sie eine Umgebungsvariable mit dem NamenPATH
und einem Wert von$PATH:/usr/share/ant/bin
festlegen, wird/usr/local/sbin:/usr/local/bin
durch den Literalwert$PATH:/usr/share/ant/bin
ersetzt.Legen Sie keine Umgebungsvariable mit einem Namen fest, der mit
CODEBUILD_
beginnt. Dieses Präfix ist zur -internen Verwendung reserviert.Wenn eine Umgebungsvariable mit identischem Namen an mehreren Orten definiert ist, wird der Wert folgendermaßen bestimmt:
-
Der Wert im Aufruf zum Starten des Build-Vorgangs hat den höchsten Vorrang. Beim Erstellen eines Builds können Sie Umgebungsvariablen hinzufügen oder überschreiben. Weitere Informationen finden Sie unter Führen Sie einen Build in aus AWS CodeBuild.
-
Der Wert in der Build-Projektdefinition folgt darauf. Beim Erstellen oder Bearbeiten eines Projekts können Sie Umgebungsvariablen auf Projektebene hinzufügen. Weitere Informationen finden Sie unter Erstellen eines Build-Projekts in AWS CodeBuild und Ändern der Einstellungen eines Build-Projekts in AWS CodeBuild.
-
Der Wert in der buildspec-Deklaration hat die niedrigste Priorität.
-
- env/parameter-store
-
Erforderlich, wenn
env
angegeben, und Sie benutzerdefinierte Umgebungsvariablen abrufen möchten, die im Amazon EC2 Systems Manager Parameter Store gespeichert sind. Enthält eine Zuordnung vonkey
/value
Skalare, wobei jede Zuordnung eine einzelne benutzerdefinierte Umgebungsvariable darstellt, die im Amazon EC2 Systems Manager Parameter Store gespeichert ist.key
ist der Name, den Sie später in Ihren Build-Befehlen verwenden, um auf diese benutzerdefinierte Umgebungsvariable zu verweisen, undvalue
ist der Name der benutzerdefinierten Umgebungsvariablen, die im Amazon EC2 Systems Manager Parameter Store gespeichert ist. Informationen zum Speichern sensibler Werte finden Sie unter Systems Manager Parameter Store and Walkthrough: Create and test a String parameters (console) im Amazon EC2 Systems Manager Manager-Benutzerhandbuch.Wichtig
Um das Abrufen von benutzerdefinierten Umgebungsvariablen CodeBuild zu ermöglichen, die im Amazon EC2 Systems Manager Parameter Store gespeichert sind, müssen Sie die
ssm:GetParameters
Aktion zu Ihrer CodeBuild Servicerolle hinzufügen. Weitere Informationen finden Sie unter Erstellen Sie eine CodeBuild Servicerolle.Alle Umgebungsvariablen, die Sie aus dem Amazon EC2 Systems Manager Parameter Store abrufen, ersetzen bestehende Umgebungsvariablen. Wenn das Docker-Image beispielsweise bereits eine Umgebungsvariable mit dem Namen
MY_VAR
und einem Wert vonmy_value
enthält und Sie eine Umgebungsvariable mit dem NamenMY_VAR
und einem Wert vonother_value
abrufen, wirdmy_value
durchother_value
ersetzt. Wenn das Docker-Image demgegenüber bereits eine Umgebungsvariable mit dem NamenPATH
und einem Wert von/usr/local/sbin:/usr/local/bin
enthält und Sie eine Umgebungsvariable mit dem NamenPATH
und einem Wert von$PATH:/usr/share/ant/bin
abrufen, wird/usr/local/sbin:/usr/local/bin
durch den Literalwert$PATH:/usr/share/ant/bin
ersetzt.Speichern Sie keine Umgebungsvariable mit einem Namen, der mit
CODEBUILD_
beginnt. Dieses Präfix ist zur -internen Verwendung reserviert.Wenn eine Umgebungsvariable mit identischem Namen an mehreren Orten definiert ist, wird der Wert folgendermaßen bestimmt:
-
Der Wert im Aufruf zum Starten des Build-Vorgangs hat den höchsten Vorrang. Beim Erstellen eines Builds können Sie Umgebungsvariablen hinzufügen oder überschreiben. Weitere Informationen finden Sie unter Führen Sie einen Build in aus AWS CodeBuild.
-
Der Wert in der Build-Projektdefinition folgt darauf. Beim Erstellen oder Bearbeiten eines Projekts können Sie Umgebungsvariablen auf Projektebene hinzufügen. Weitere Informationen finden Sie unter Erstellen eines Build-Projekts in AWS CodeBuild und Ändern der Einstellungen eines Build-Projekts in AWS CodeBuild.
-
Der Wert in der buildspec-Deklaration hat die niedrigste Priorität.
-
- env/secrets-manager
-
Erforderlich, wenn Sie benutzerdefinierte Umgebungsvariablen abrufen möchten, die in gespeichert sind AWS Secrets Manager. Geben Sie einen Secrets Manager
reference-key
mit dem folgenden Muster an:
:<key>
<secret-id>
:<json-key>
:<version-stage>
:<version-id>
<key>
-
(Erforderlich) Der Name der lokalen Umgebungsvariablen. Verwenden Sie diesen Namen, um während des Builds auf die Variable zuzugreifen.
<secret-id>
-
(Erforderlich) Der Name oder der Amazon-Ressourcenname (ARN), der als eindeutige Kennung für das Geheimnis dient. Um auf ein Secret in Ihrem AWS -Konto zuzugreifen, geben Sie einfach den Secret-Namen an. Um auf ein Geheimnis in einem anderen AWS Konto zuzugreifen, geben Sie das Geheimnis anARN.
<json-key>
-
(Optional) Gibt den Schlüsselnamen des Secrets Manager Manager-Schlüssel-Wert-Paares an, dessen Wert Sie abrufen möchten. Wenn Sie kein a angeben
json-key
, wird der gesamte CodeBuild geheime Text abgerufen. <version-stage>
-
(Optional) Gibt die geheime Version, die Sie abrufen möchten, anhand des der Version beigefügten Staging-Labels an. Staging-Kennzeichnungen werden verwendet, um während des Rotationsprozesses den Überblick über verschiedene Versionen zu behalten. Wenn Sie
version-stage
verwenden, geben Sieversion-id
nicht an. Wenn Sie keine Versionsstufe oder Versions-ID angeben, wird standardmäßig die Version mit dem VersionsstufenwertAWSCURRENT
abgerufen. <version-id>
-
(Optional) Gibt den eindeutigen Bezeichner der Version des Secrets an, die Sie verwenden möchten. Wenn Sie
version-id
angeben, dürfen Sieversion-stage
nicht angeben. Wenn Sie keine Versionsstufe oder Versions-ID angeben, wird standardmäßig die Version mit dem VersionsstufenwertAWSCURRENT
abgerufen.
Im folgenden Beispiel
TestSecret
ist der Name des Schlüssel-Wert-Paares in Secrets Manager gespeichert. Der Schlüssel fürTestSecret
ist.MY_SECRET_VAR
Sie greifen während des Builds über denLOCAL_SECRET_VAR
Namen auf die Variable zu.env: secrets-manager: LOCAL_SECRET_VAR: "TestSecret:MY_SECRET_VAR"
Weitere Informationen finden Sie unter Was ist AWS Secrets Manager? im AWS Secrets Manager -Benutzerhandbuch.
- env/exported-variables
-
Optionale Zuweisung. Wird verwendet, um Umgebungsvariablen aufzulisten, die Sie exportieren möchten. Geben Sie den Namen jeder Variable, die Sie exportieren möchten, unter
exported-variables
in einer separaten Zeile an. Die Variable, die Sie exportieren möchten, muss während des Builds in Ihrem Container verfügbar sein. Die Variable, die Sie exportieren, kann eine Umgebungsvariable sein.Exportierte Umgebungsvariablen werden in Verbindung mit verwendet AWS CodePipeline , um Umgebungsvariablen aus der aktuellen Buildphase in nachfolgende Phasen der Pipeline zu exportieren. Weitere Informationen finden Sie im AWS CodePipeline Benutzerhandbuch unter Arbeiten mit Variablen.
Während eines Builds ist der Wert einer Variablen ab der
install
-Phase verfügbar. Er kann zwischen dem Beginn derinstall
-Phase und dem Ende derpost_build
-Phase aktualisiert werden. Nach dem Ende derpost_build
-Phase kann sich der Wert der exportierten Variablen nicht ändern.Anmerkung
Folgendes kann nicht exportiert werden:
-
Amazon EC2 Systems Manager Parameter Speichert die im Build-Projekt angegebenen Geheimnisse.
-
Secrets Manager Manager-Geheimnisse, die im Build-Projekt angegeben wurden
-
Umgebungsvariablen, die mit
AWS_
beginnen.
-
- env/ git-credential-helper
-
Optionale Zuweisung. Wird verwendet, um anzugeben, ob sein Git-Helper für Anmeldeinformationen CodeBuild verwendet wird, um Git-Anmeldeinformationen bereitzustellen.
yes
ob es verwendet wird. Andernfallsno
oder nicht angegeben. Weitere Informationen finden Sie unter gitcredentialsauf der Git-Website. Anmerkung
git-credential-helper
wird für Builds, die von einem Webhook für ein öffentliches Git-Repository ausgelöst werden, nicht unterstützt.
Proxy
Optionale Sequenz. Wird verwendet, um Einstellungen darzustellen, wenn Sie Ihren Build in einem expliziten Proxy-Server ausführen. Weitere Informationen finden Sie unter CodeBuild Auf einem expliziten Proxyserver ausführen.
- proxy/upload-artifacts
-
Optionale Zuweisung. Legen Sie diese auf
yes
fest, wenn Ihr Build in einem expliziten Proxy-Server Artefakte hochladen soll. Der Standardwert istno
. - proxy/logs
-
Optionale Zuweisung. Stellen Sie auf ein,
yes
damit Ihr Build einen expliziten Proxyserver zur Erstellung von CloudWatch Protokollen einfügt. Der Standardwert istno
.
phases
Erforderliche Sequenz. Stellt die Befehle dar, die in jeder Phase des Builds CodeBuild ausgeführt werden.
Anmerkung
CodeBuild Führt in Buildspec-Version 0.1 jeden Befehl in einer separaten Instanz der Standard-Shell in der Build-Umgebung aus. d. h., dass jeder Befehl unabhängig von allen anderen Befehlen ausgeführt wird. Daher können Sie standardmäßig keinen Einzelbefehl ausführen, der auf dem Status eines vorherigen Befehls basiert (beispielsweise beim Ändern von Verzeichnissen oder beim Einrichten von Variablen). Um diese Einschränkung zu umgehen, empfehlen wir die Nutzung von Version 0.2, die dieses Problem löst. Wenn Sie die Build-Spezifikation Version 0.1 verwenden müssen, empfehlen wir die Ansätze in Shells und Befehle in Build-Umgebungen.
- phases/*/run-as
-
Optionale Sequenz. Verwenden Sie den Befehl in einer Build-Phase, um den Linux-Benutzer festzulegen, der die zugehörigen Befehle ausführt. Wenn zusätzlich zu Beginn der buildspec-Datei
run-as
global für alle Befehle angegeben wird, wird dem Benutzer auf Phasenebene Vorrang eingeräumt. Beispiel: Wennrun-as
global User-1 angibt und in derinstall
-Phase einerun-as
-Anweisung User-2 definiert, werden alle Befehle in der buildspec-Datei als User-1 ausgeführt, bis auf die Befehle in derinstall
-Phase, die als User-2 ausgeführt werden. - phasen/*/ bei einem Fehler
-
Optionale Sequenz. Gibt die Aktion an, die ergriffen werden soll, wenn während der Phase ein Fehler auftritt. Dabei kann es sich um einen der folgenden Werte handeln:
-
ABORT
- Bricht den Build ab. -
CONTINUE
- Fahren Sie mit der nächsten Phase fort.
Wenn diese Eigenschaft nicht angegeben ist, folgt der Fehlerprozess den Übergangsphasen, wie unter beschriebenÜbergang von Build-Phasen.
-
- Phasen/*/ schließlich
-
Optionaler Block. In einem
finally
Block angegebene Befehle werden nach Befehlen im Block ausgeführt.commands
Die Befehle in einemfinally
Block werden auch dann ausgeführt, wenn ein Befehl imcommands
Block fehlschlägt. Wenn dercommands
Block beispielsweise drei Befehle enthält und der erste fehlschlägt, werden die verbleibenden zwei Befehle CodeBuild übersprungen und alle Befehle imfinally
Block ausgeführt. Die Phase ist erfolgreich, wenn alle Befehle in den Blöckencommands
undfinally
erfolgreich ausgeführt werden. Wenn ein Befehl in einer Phase fehlschlägt, schlägt die Phase fehl.
Die zulässigen Build-Phasennamen sind:
- phases/install
-
Optionale Sequenz. Stellt die Befehle dar, falls vorhanden, die während der Installation CodeBuild ausgeführt werden. Wir empfehlen Ihnen, die Phase
install
nur für Installationspakete in der Build-Umgebung einzusetzen. Sie könnten diese Phase beispielsweise verwenden, um ein Code-Test-Framework wie Mocha oder RSpec zu installieren.- phases/install/runtime-versions
-
Optionale Sequenz. Eine Runtime-Version wird mit dem Ubuntu-Standard-Image 5.0 oder höher und dem Amazon Linux 2-Standard-Image 4.0 oder höher unterstützt. Wenn dieses Argument angegeben wird, muss mindestens eine Laufzeit in diesen Abschnitt aufgenommen werden. Geben Sie eine Laufzeit mit einer bestimmten Version an, eine Hauptversion, gefolgt von,
.x
um anzugeben, dass diese Hauptversion mit ihrer neuesten Nebenversion CodeBuild verwendet wird, oderlatest
um die neueste Haupt- und Nebenversion zu verwenden (z. B.ruby: 3.2
,nodejs: 18.x
, oderjava: latest
). Sie können die Laufzeit unter Verwendung einer Zahl oder einer Umgebungsvariablen angeben. Wenn Sie beispielsweise das Amazon Linux 2-Standard-Image 4.0 verwenden, wird im Folgenden angegeben, dass Version 17 von Java, die neueste Nebenversion von Python Version 3 und eine Version, die in einer Umgebungsvariablen von Ruby enthalten ist, installiert sind. Weitere Informationen finden Sie unter Docker-Images bereitgestellt von CodeBuild.phases: install: runtime-versions: java: corretto8 python: 3.x ruby: "$MY_RUBY_VAR"
Sie können eine oder mehrere Laufzeiten im Abschnitt
runtime-versions
Ihrer buildspec-Datei angeben. Wenn Ihre Laufzeit von einer anderen Laufzeit abhängig ist, können Sie auch die abhängige Laufzeit in der buildspec-Datei angeben. Wenn Sie in der Buildspec-Datei keine Laufzeiten angeben, CodeBuild wählt die Standard-Laufzeiten, die in dem von Ihnen verwendeten Image verfügbar sind. Wenn Sie eine oder mehrere Laufzeiten angeben, werden nur diese Laufzeiten verwendet. CodeBuild Wenn keine abhängige Laufzeit angegeben ist, wird CodeBuild versucht, die abhängige Laufzeit für Sie auszuwählen.Wenn zwei angegebene Laufzeiten unvereinbar sind, schlägt der Build fehl. Beispiel:
android: 29
undjava: openjdk11
sind miteinander unvereinbar. Wenn beide angegeben werden, schlägt der Build fehl.Weitere Hinweise zu den verfügbaren Laufzeiten finden Sie unterVerfügbare Laufzeiten.
Anmerkung
Wenn Sie einen
runtime-versions
Abschnitt angeben und ein anderes Image als Ubuntu Standard Image 2.0 oder höher oder das Amazon Linux 2 (AL2) Standard Image 1.0 oder höher verwenden, gibt der Build die Warnung "“ ausSkipping install of runtimes. Runtime version selection is not supported by this build image
.
- phases/install/commands
-
Optionale Sequenz. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen einzelnen Befehl steht, der während der Installation CodeBuild ausgeführt wird. CodeBuild führt jeden Befehl nacheinander in der angegebenen Reihenfolge von Anfang bis Ende aus.
- phases/pre_build
-
Optionale Sequenz. Stellt die Befehle dar, falls vorhanden, die vor dem Build CodeBuild ausgeführt werden. Sie können diese Phase beispielsweise verwenden, um sich bei Amazon anzumeldenECR, oder Sie können npm-Abhängigkeiten installieren.
- phases/pre_build/commands
-
Erforderliche Sequenz, wenn
pre_build
angegeben ist. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen einzelnen Befehl steht, der vor dem Build CodeBuild ausgeführt wird. CodeBuildführt jeden Befehl nacheinander in der angegebenen Reihenfolge von Anfang bis Ende aus.
- phases/build
-
Optionale Sequenz. Stellt die Befehle dar, falls vorhanden, die während des Builds CodeBuild ausgeführt werden. Sie könnten diese Phase beispielsweise verwenden, um Mocha,RSpec, oder sbt auszuführen.
- phases/build/commands
-
Erforderlich, wenn
build
angegeben. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen einzelnen Befehl steht, der während des CodeBuild Builds ausgeführt wird. CodeBuild führt jeden Befehl nacheinander in der angegebenen Reihenfolge von Anfang bis Ende aus.
- phases/post_build
-
Optionale Sequenz. Stellt die Befehle dar, sofern vorhanden, die nach dem Build CodeBuild ausgeführt werden. Sie könnten beispielsweise Maven verwenden, um die Build-Artefakte in eine JAR WAR OR-Datei zu packen, oder Sie könnten ein Docker-Image in Amazon pushen. ECR Dann können Sie eine Build-Benachrichtigung über Amazon sendenSNS.
- phases/post_build/commands
-
Erforderlich,
post_build
wenn angegeben. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen einzelnen Befehl steht, der nach dem CodeBuild Build ausgeführt wird. CodeBuild führt jeden Befehl nacheinander in der angegebenen Reihenfolge von Anfang bis Ende aus.
Berichte
- report-group-name-or-arn
-
Optionale Sequenz. Gibt die Berichtsgruppe an, an die die Berichte gesendet werden. Ein Projekt kann maximal fünf Berichtsgruppen haben. Geben Sie den Namen ARN einer vorhandenen Berichtsgruppe oder den Namen einer neuen Berichtsgruppe an. Wenn Sie einen Namen angeben, CodeBuild erstellt eine Berichtsgruppe mit Ihrem Projektnamen und dem Namen, den Sie im Format angeben
<project-name>-<report-group-name>
. Der Name der Berichtsgruppe kann auch mithilfe einer Umgebungsvariablen in der Buildspec festgelegt werden, z. B.$REPORT_GROUP_NAME
Weitere Informationen finden Sie unter Benennung von Berichtsgruppen. - reports/<report-group>/files
-
Erforderliche Sequenz. Stellt die Speicherorte dar, die die Rohdaten der vom Bericht generierten Testergebnisse enthalten. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem Testdateien gefunden CodeBuild werden können, und zwar relativ zum ursprünglichen Build-Speicherort oder, falls festgelegt, zum.
base-directory
Speicherorte können Folgendes enthalten:-
Eine Einzeldatei (z. B.
my-test-report-file.json
). -
Eine einzelne Datei in einem Unterverzeichnis (Beispiel:
odermy-subdirectory
/my-test-report-file.json
).my-parent-subdirectory
/my-subdirectory
/my-test-report-file.json -
'**/*'
steht rekursiv für alle Dateien. -
steht für alle Dateien in einem Unterverzeichnis mit dem Namenmy-subdirectory
/*my-subdirectory
. -
repräsentiert alle Dateien rekursiv, beginnend mit einem Unterverzeichnis mit dem Namenmy-subdirectory
/**/*my-subdirectory
.
-
- reports/<report-group>/file-format
-
Optionale Zuweisung. Stellt das Berichtsdateiformat dar. Wenn nicht angegeben, wird
JUNITXML
verwendet. Bei diesem Wert wird nicht zwischen Groß- und Kleinschreibung unterschieden. Die möglichen Werte sind:Testberichte
-
CUCUMBERJSON
-
Gurke JSON
-
JUNITXML
-
JUnit XML
-
NUNITXML
-
NUnit XML
-
NUNIT3XML
-
NUnit3 XML
-
TESTNGXML
-
TestNG XML
-
VISUALSTUDIOTRX
-
Visual Studio TRX
Berichte zur Codeabdeckung
-
CLOVERXML
-
Klee XML
-
COBERTURAXML
-
Covertura XML
-
JACOCOXML
-
JaCoCo XML
-
SIMPLECOV
-
SimpleCov JSON
-
- reports/<report-group>/base-directory
-
Optionale Zuweisung. Stellt ein oder mehrere Verzeichnisse auf oberster Ebene im Verhältnis zum ursprünglichen Build-Speicherort dar, anhand derer bestimmt wird, wo sich die CodeBuild Rohtestdateien befinden.
- reports/<report-group>/discard-paths
-
Optional. Gibt an, ob die Berichtsdateiverzeichnisse in der Ausgabe abgeflacht werden. Wenn dies nicht angegeben ist oder
no
enthält, werden Berichtsdateien mit intakter Verzeichnisstruktur ausgegeben. Wenn diesyes
enthält, werden alle Testdateien im selben Ausgabeverzeichnis abgelegt. Wenn beispielsweise ein Pfad zu einem Testergebniscom/myapp/mytests/TestResult.xml
lautet, wird die Datei durch Angabe vonyes
in/TestResult.xml
gespeichert.
Artefakte
Optionale Sequenz. Stellt Informationen darüber dar, wo die Build-Ausgabe zu CodeBuild finden ist und wie sie für den Upload in den S3-Ausgabe-Bucket CodeBuild vorbereitet wird. Diese Reihenfolge ist nicht erforderlich, wenn Sie beispielsweise ein Docker-Image erstellen und an Amazon ECR übertragen oder wenn Sie Komponententests für Ihren Quellcode ausführen, ihn aber nicht erstellen.
Anmerkung
Amazon S3-Metadaten haben einen CodeBuild Header namensx-amz-meta-codebuild-buildarn
, buildArn
der den CodeBuild Build enthält, der Artefakte in Amazon S3 veröffentlicht. Der buildArn
wurde hinzugefügt, um die Quellenverfolgung für Benachrichtigungen zu ermöglichen und um zu referenzieren, aus welchem Build das Artefakt generiert wurde.
- artifacts/files
-
Erforderliche Sequenz. Diese stellt die Speicherorte dar, die die Build-Ausgabeartefakte in der Build-Umgebung enthalten. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem Build-Ausgabeartefakte gefunden werden CodeBuild können, und zwar relativ zum ursprünglichen Build-Speicherort oder, falls festgelegt, zum Basisverzeichnis. Speicherorte können Folgendes enthalten:
-
Eine Einzeldatei (z. B.
my-file.jar
). -
Eine einzelne Datei in einem Unterverzeichnis (Beispiel:
odermy-subdirectory
/my-file.jar
).my-parent-subdirectory
/my-subdirectory
/my-file.jar -
'**/*'
steht rekursiv für alle Dateien. -
steht für alle Dateien in einem Unterverzeichnis mit dem Namenmy-subdirectory
/*my-subdirectory
. -
repräsentiert alle Dateien rekursiv, beginnend mit einem Unterverzeichnis mit dem Namenmy-subdirectory
/**/*my-subdirectory
.
Wenn Sie Speicherorte für Build-Ausgabeartefakte angeben, CodeBuild kann der ursprüngliche Build-Speicherort in der Build-Umgebung gefunden werden. Sie müssen die Speicherorte von Build-Ausgabeartefakten mit dem Pfad zu den ursprünglichen Build-Speicherorten nicht voranstellen oder angeben,
./
oder ähnliches. Wenn sie den Pfad zu diesem Speicherort wissen möchten, können Sie während eines Builds ein Befehl ausführen wieecho $CODEBUILD_SRC_DIR
. Der Speicherort für jede Build-Umgebung kann geringfügig voneinander abweichen. -
- artifacts/name
-
Optionaler Name. Gibt einen Namen für Ihr Build-Artefakt an. Dieser Name wird verwendet, wenn eine der folgenden Bedingungen zutrifft.
-
Sie verwenden den CodeBuild API, um Ihre Builds zu erstellen, und das
overrideArtifactName
Flag wird auf demProjectArtifacts
Objekt gesetzt, wenn ein Projekt aktualisiert, ein Projekt erstellt oder ein Build gestartet wird. -
Sie verwenden die CodeBuild Konsole, um Ihre Builds zu erstellen, in der Buildspec-Datei wird ein Name angegeben und Sie wählen Semantische Versionierung aktivieren, wenn Sie ein Projekt erstellen oder aktualisieren. Weitere Informationen finden Sie unter Erstellen Sie ein Build-Projekt (Konsole).
Sie können einen Namen in der Build-Spezifikationsdatei angeben, die zur Build-Zeit berechnet wird. Der in einer Build-Spezifikationsdatei angegebene Name verwendet die Shell-Befehlssprache. Beispielsweise können Sie dem Namen Ihres Artefakts ein Datum und eine Uhrzeit anhängen, damit dieser stets eindeutig ist. Eindeutige Artefakt-Namen verhindern, dass Artefakte überschrieben werden. Weitere Informationen finden Sie unter Shell-Befehlssprache
. -
Dies ist ein Beispiel für einen Artefakt-Namen, dem das Datum angefügt wurde, an dem das Artefakt erstellt wurde.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$(date +%Y-%m-%d)
-
Dies ist ein Beispiel für einen Artefaktnamen, der eine Umgebungsvariable verwendet. CodeBuild Weitere Informationen finden Sie unter Umgebungsvariablen in Build-Umgebungen.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$AWS_REGION
-
Dies ist ein Beispiel für einen Artefaktnamen, der eine CodeBuild Umgebungsvariable verwendet, an die das Erstellungsdatum des Artefakts angehängt wird.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: $AWS_REGION-$(date +%Y-%m-%d)
Sie können dem Namen Pfadinformationen hinzufügen, sodass die benannten Artefakte auf der Grundlage des Pfads im Namen in Verzeichnissen platziert werden. In diesem Beispiel werden Build-Artefakte in der Ausgabe unter platziert
builds/<build number>/my-artifacts
.version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: builds/$CODEBUILD_BUILD_NUMBER/my-artifacts
-
- artifacts/discard-paths
-
Optional. Gibt an, ob die Build-Artefaktnerzeichnisse in der Ausgabe abgeflacht werden. Wenn dies nicht angegeben ist oder
no
enthält, werden Build-Artefakte mit intakter Verzeichnisstruktur ausgegeben. Wennyes
enthalten ist, werden alle Build-Artefakte im selben Ausgabeverzeichnis platziert. Wenn beispielsweise ein Pfad zu einer Datei im Build-Ausgabeartefaktcom/mycompany/app/HelloWorld.java
ist, wird diese Datei durch Angabe vonyes
in/HelloWorld.java
gespeichert. - artifacts/base-directory
-
Optionale Zuweisung. Stellt relativ zum ursprünglichen Build-Speicherort ein oder mehrere Verzeichnisse der obersten Ebene dar, anhand derer bestimmt CodeBuild wird, welche Dateien und Unterverzeichnisse in das Build-Ausgabeartefakt aufgenommen werden sollen. Gültige Werte sind:
-
Ein einziges Top-Level-Verzeichnis (z. B.
my-directory
). -
'my-directory*'
stellt alle Top-Level-Verzeichnisse dar, deren Namen mitmy-directory
beginnen.
Die übereinstimmenden Top-Level-Verzeichnisse werden nicht in den Build-Ausgabeartefakt aufgenommen, sondern nur deren Dateien und Unterverzeichnisse.
Sie können
files
unddiscard-paths
verwenden, um weiter zu beschränken, welche Dateien und Unterverzeichnisse aufgenommen werden. Wie zum Beispiel für die folgende Verzeichnisstruktur:. ├── my-build-1 │ └── my-file-1.txt └── my-build-2 ├── my-file-2.txt └── my-subdirectory └── my-file-3.txt
Und für die folgende Sequenz
artifacts
:artifacts: files: - '*/my-file-3.txt' base-directory: my-build-2
Das folgende Unterverzeichnis und die Datei werden in den Build-Ausgabeartefakt aufgenommen:
. └── my-subdirectory └── my-file-3.txt
Während für die Sequenz
artifacts
Folgendes gilt:artifacts: files: - '**/*' base-directory: 'my-build*' discard-paths: yes
Die folgenden Dateien werden in den Build-Ausgabeartefakt aufgenommen:
. ├── my-file-1.txt ├── my-file-2.txt └── my-file-3.txt
-
- Artefakte/Ausschlusspfade
-
Optionale Zuweisung. Steht für einen oder mehrere Pfade, relativ zu
base-directory
, die Artefakte aus dem CodeBuild Build ausschließen. Das Sternchen (*
) entspricht einem oder mehreren Zeichen einer Namenskomponente ohne Überschreiten der Ordnergrenzen. Ein doppeltes Sternchen (**
) steht für null oder mehr Zeichen einer Namenskomponente in allen Verzeichnissen.Beispiele für Ausschlusspfade sind die folgenden:
-
Um eine Datei aus allen Verzeichnissen auszuschließen:
"**/
file-name
/**/*" -
Um alle Punktordner auszuschließen:
"**/.*/**/*"
-
Um alle Punktdateien auszuschließen:
"**/.*"
-
- Artefakte/ aktivieren-Symlinks
-
Optional. Wenn der Ausgabetyp ist
ZIP
, gibt er an, ob interne symbolische Links in der Datei erhalten bleiben. ZIP Wenn dieser Wert enthältyes
, werden alle internen symbolischen Links in der Quelle in der ZIP Artefaktdatei beibehalten. - Artefakte/ s3-Präfix
-
Optional. Gibt ein Präfix an, das verwendet wird, wenn die Artefakte in einen Amazon S3 S3-Bucket ausgegeben werden, und der Namespace-Typ ist
BUILD_ID
. Bei Verwendung lautet<s3-prefix>/<build-id>/<name>.zip
der Ausgabepfad im Bucket. - artifacts/secondary-artifacts
-
Optionale Sequenz. Repräsentiert einzelne oder mehrere Artefaktdefinitionen als Zuordnung zwischen einem Artefaktbezeichner und einer Artefaktdefinition. Jeder Artefaktbezeichner in diesem Block muss einem im Attribut
secondaryArtifacts
des Projekts definierten Artefakt entsprechen. Jede separate Definition hat die gleiche Syntax wie derartifacts
-Block oben.Anmerkung
Die artifacts/filesReihenfolge ist immer erforderlich, auch wenn nur sekundäre Artefakte definiert sind.
Angenommen sei ein Projekt mit folgender Struktur:
{ "name": "sample-project", "secondaryArtifacts": [ { "type": "S3", "location": "
<output-bucket1>
", "artifactIdentifier": "artifact1", "name": "secondary-artifact-name-1" }, { "type": "S3", "location": "<output-bucket2>
", "artifactIdentifier": "artifact2", "name": "secondary-artifact-name-2" } ] }Anschließend sieht die buildspec-Datei wie folgt aus:
version: 0.2 phases: build: commands: - echo Building... artifacts: files: - '**/*' secondary-artifacts: artifact1: files: - directory/file1 name: secondary-artifact-name-1 artifact2: files: - directory/file2 name: secondary-artifact-name-2
Cache
Optionale Sequenz. Stellt Informationen darüber dar, CodeBuild wo die Dateien für das Hochladen des Caches in einen S3-Cache-Bucket vorbereitet werden können. Diese Sequenz ist nicht erforderlich, wenn der Cache-Typ des Projekts No Cache
ist.
- cache/paths
-
Erforderliche Sequenz. Steht für die Speicherorte des Caches. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem Build-Ausgabeartefakte gefunden werden CodeBuild können, und zwar relativ zum ursprünglichen Build-Speicherort oder, falls festgelegt, zum Basisverzeichnis. Speicherorte können Folgendes enthalten:
-
Eine Einzeldatei (z. B.
my-file.jar
). -
Eine einzelne Datei in einem Unterverzeichnis (Beispiel:
odermy-subdirectory
/my-file.jar
).my-parent-subdirectory
/my-subdirectory
/my-file.jar -
'**/*'
steht rekursiv für alle Dateien. -
steht für alle Dateien in einem Unterverzeichnis mit dem Namenmy-subdirectory
/*my-subdirectory
. -
repräsentiert alle Dateien rekursiv, beginnend mit einem Unterverzeichnis mit dem Namenmy-subdirectory
/**/*my-subdirectory
.
-
Wichtig
Da eine Buildspec-Deklaration gültig sein mussYAML, ist der Abstand in einer Buildspec-Deklaration wichtig. Wenn die Anzahl der Leerzeichen in der Build-Spezifikationsdeklaration unzulässig ist, können die Builds sofort fehlschlagen. Sie können einen YAML Validator verwenden, um zu testen, ob Ihre Buildspec-Deklarationen gültig sind. YAML
Wenn Sie beim Erstellen oder Aktualisieren eines Buildprojekts die oder die deklarieren AWS CLI, AWS SDKs um eine Buildspezifikation zu deklarieren, muss es sich bei der Buildspec um eine einzelne Zeichenfolge handeln, die im YAML Format ausgedrückt wird, zusammen mit den erforderlichen Leerzeichen und Escape-Zeichen für Zeilenumbrüche. Es folgt ein Beispiel im nächsten Abschnitt.
Wenn Sie die AWS CodePipeline Konsolen CodeBuild oder anstelle einer buildspec.yml-Datei verwenden, können Sie Befehle nur für die Phase einfügen. build
Statt die vorherige Syntax zu verwenden, geben Sie in einer einzigen Ziele sämtliche Befehle an, die Sie während der Build-Phase verwenden möchten. Bei mehreren Befehlen unterteilen Sie die einzelnen Befehle mit &&
, (wie z. B. mvn test && mvn
package
).
Sie können die CodePipeline Konsolen CodeBuild oder anstelle einer buildspec.yml-Datei verwenden, um die Speicherorte der Build-Ausgabeartefakte in der Buildumgebung anzugeben. Statt die vorherige Syntax zu verwenden, geben Sie in einer einzigen Ziele sämtliche Speicherorte an. Bei mehreren Speicherorten trennen Sie die einzelnen Speicherorte durch ein Komma, (wie z. B. buildspec.yml, target/my-app.jar
).
Beispiel für eine Build-Spezifikation
Hier finden Sie ein Beispiel für eine Datei buildspec.yml.
version: 0.2 env: variables: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" parameter-store: LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword phases: install: commands: - echo Entered the install phase... - apt-get update -y - apt-get install -y maven finally: - echo This always runs even if the update or install command fails pre_build: commands: - echo Entered the pre_build phase... - docker login -u User -p $LOGIN_PASSWORD finally: - echo This always runs even if the login command fails build: commands: - echo Entered the build phase... - echo Build started on `date` - mvn install finally: - echo This always runs even if the install command fails post_build: commands: - echo Entered the post_build phase... - echo Build completed on `date` reports: arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1: files: - "**/*" base-directory: 'target/tests/reports' discard-paths: no reportGroupCucumberJson: files: - 'cucumber/target/cucumber-tests.xml' discard-paths: yes file-format: CUCUMBERJSON # default is JUNITXML artifacts: files: - target/messageUtil-1.0.jar discard-paths: yes secondary-artifacts: artifact1: files: - target/artifact-1.0.jar discard-paths: yes artifact2: files: - target/artifact-2.0.jar discard-paths: yes cache: paths: - '/root/.m2/**/*'
Hier ist ein Beispiel für die vorangegangene Buildspec, ausgedrückt als einzelne Zeichenfolge, zur Verwendung mit, oder dem. AWS CLI AWS SDKs
"version: 0.2\n\nenv:\n variables:\n JAVA_HOME: \"/usr/lib/jvm/java-8-openjdk-amd64\\"\n parameter-store:\n LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword\n phases:\n\n install:\n commands:\n - echo Entered the install phase...\n - apt-get update -y\n - apt-get install -y maven\n finally:\n - echo This always runs even if the update or install command fails \n pre_build:\n commands:\n - echo Entered the pre_build phase...\n - docker login -u User -p $LOGIN_PASSWORD\n finally:\n - echo This always runs even if the login command fails \n build:\n commands:\n - echo Entered the build phase...\n - echo Build started on `date`\n - mvn install\n finally:\n - echo This always runs even if the install command fails\n post_build:\n commands:\n - echo Entered the post_build phase...\n - echo Build completed on `date`\n\n reports:\n reportGroupJunitXml:\n files:\n - \"**/*\"\n base-directory: 'target/tests/reports'\n discard-paths: false\n reportGroupCucumberJson:\n files:\n - 'cucumber/target/cucumber-tests.xml'\n file-format: CUCUMBERJSON\n\nartifacts:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n secondary-artifacts:\n artifact1:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n artifact2:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n cache:\n paths:\n - '/root/.m2/**/*'"
Hier ist ein Beispiel für die Befehle in der build
Phase zur Verwendung mit den CodeBuild Oder-Konsolen. CodePipeline
echo Build started on `date` && mvn install
In diesen Beispielen gilt:
-
Eine benutzerdefinierte Klartext-Umgebungsvariable mit dem Schlüssel
JAVA_HOME
und dem Wert/usr/lib/jvm/java-8-openjdk-amd64
wird eingerichtet. -
Auf eine benutzerdefinierte Umgebungsvariable mit dem Namen, die
dockerLoginPassword
Sie im Amazon EC2 Systems Manager Parameter Store gespeichert haben, wird später in Build-Befehlen mithilfe des Schlüssels verwiesenLOGIN_PASSWORD
. -
Sie können diese Build-Phasennamen nicht ändern. Die Befehle, die in diesem Beispiel ausgeführt werden, sind
apt-get update -y
undapt-get install -y maven
(um Apache Maven zu installieren),mvn install
(um den Quellcode zu kompilieren, zu testen und in ein Build-Ausgabeartefakt zu packen und das Build-Ausgabeartefakt in seinem internen Repository zu installieren),docker login
(um sich bei Docker mit dem Passwort anzumelden, das dem Wert der benutzerdefinierten Umgebungsvariablen entspricht, diedockerLoginPassword
Sie im Amazon EC2 Systems Manager Parameter Store festgelegt haben) und mehrere Befehle.echo
Dieecho
Befehle sind hier enthalten, um zu zeigen, wie Befehle CodeBuild ausgeführt werden und in welcher Reihenfolge sie ausgeführt werden. -
files
stellt die Dateien dar, die in den Build-Ausgabespeicherort hochgeladen werden sollen. CodeBuild Lädt in diesem Beispiel die einzelne DateimessageUtil-1.0.jar
hoch. Die DateimessageUtil-1.0.jar
ist in dem jeweiligen Verzeichnis mit Namentarget
in der Build-Umgebung zu finden. Dadiscard-paths: yes
angegeben wird, wirdmessageUtil-1.0.jar
direkt hochgeladen (und nicht an ein intermediäres Verzeichnis mit dem Namentarget
). Der DateinamemessageUtil-1.0.jar
und der dazugehörige Verzeichnisname vontarget
basiert auf der Weise, wie - nur für dieses Beispiel - unter den Apache Maven Build-Ausgabeartefakte erstellt und gespeichert werden. In Ihren eigenen Szenarios lauten diese Dateinamen und Verzeichnisse anders. -
reports
stellt zwei Berichtsgruppen dar, die während des Builds Berichte generieren:-
arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1
gibt die ARN einer Berichtsgruppe an. Testergebnisse, die vom Test-Framework generiert werden, befinden sich im Verzeichnistarget/tests/reports
. Das Dateiformat istJunitXml
und der Pfad wird nicht aus den Dateien entfernt, die Testergebnisse enthalten. -
reportGroupCucumberJson
gibt eine neue Berichtsgruppe an. Wenn der Name des Projektsmy-project
lautet, wird beim Ausführen eines Builds eine Berichtsgruppe mit dem Namenmy-project-reportGroupCucumberJson
erstellt. Testergebnisse, die vom Test-Framework generiert werden, befinden sich incucumber/target/cucumber-tests.xml
. Das Testdateiformat istCucumberJson
und der Pfad wird aus den Dateien entfernt, die Testergebnisse enthalten.
-
Versionen der Build-Spezifikationen
In der folgenden Tabelle werden Versionen von Build-Spezifikationen und die Änderungen zwischen den Versionen aufgeführt.
Version | Änderungen |
---|---|
0.2 |
|
0.1 | Dies ist die erste Definition des Build-Spezifikationsformats. |