Build-Spezifikationsreferenz für CodeBuild
Dieses Thema enthält wichtige Referenzinformationen zu Build-Spezifikationsdateien (buildspec). A buildspec is a collection of build commands and related settings, in YAML format, that CodeBuild uses to run a build. Sie können eine Build-Spezifikation als Teil des Quellcodes einschließen oder eine Build-Spezifikation definieren, wenn Sie ein Build-Projekt erstellen. Informationen zur Funktionsweise einer Build-Spezifikation finden Sie unter Funktionsweise von CodeBuild.
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 können Sie:
-
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 das Build-Projekt befinden. Geben Sie die buildspec-Datei mit ihrem ARN an (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 Befehl AWS CLI
create-project
oderupdate-project
aus und setzen Sie den Wertbuildspec
auf den Pfad zur alternativen buildspec-Datei relativ zum Wert der integrierten UmgebungsvariablenCODEBUILD_SRC_DIR
. Sie können das Äquivalent auch mit dercreate project
-Operation in der AWS SDKs durchführen. Weitere Informationen finden Sie unter Erstellen eines Build-Projekts oder Ändern der Einstellungen eines Build-Projekts. -
Führen Sie den Befehl AWS CLI
start-build
aus und setzen Sie den WertbuildspecOverride
auf den Pfad zur alternativen buildspec-Datei relativ zum Wert der integrierten UmgebungsvariablenCODEBUILD_SRC_DIR
. Entsprechend können Sie auch mit derstart build
-Operation in der AWS SDKs vorgehen. Weitere Informationen finden Sie unter Ausführen eines Build. -
Legen Sie in einer AWS CloudFormation-Vorlage die
BuildSpec
-Eigenschaft vonSource
in einer Ressource des TypsAWS::CodeBuild::Project
auf den Pfad zur alternativen Build-Spezifikationsdatei relativ zum Wert der integrierten UmgebungsvariableCODEBUILD_SRC_DIR
fest. Weitere Informationen finden Sie unter der Eigenschaft BuildSpec in der AWS CodeBuild-Projektquelle im AWS CloudFormation Benutzerhandbuch.
Syntax der Build-Spezifikation
Build-Spezifikationsdateien müssen im Format YAML
Wenn ein Befehl ein Zeichen oder eine Zeichenfolge enthält, die von YAML nicht unterstützt wird, müssen Sie den Befehl in Anführungszeichen ("") einschließen. Der folgende Befehl ist in Anführungszeichen eingeschlossen, da ein Doppelpunkt (:) gefolgt von einem Leerzeichen in YAML nicht erlaubt ist. 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
runtime-versions:runtime
:version
runtime
:version
commands: -command
-command
finally: -command
-command
pre_build: run-as:Linux-user-name
commands: -command
-command
finally: -command
-command
build: run-as:Linux-user-name
commands: -command
-command
finally: -command
-command
post_build: run-as:Linux-user-name
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
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.
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.
Zum Schutz vertraulicher Informationen wird in CodeBuild-Protokollen Folgendes ausgeblendet:
-
AWS-Zugriffsschlüssel-IDs. Weitere Informationen finden Sie unter Verwalten der Zugriffsschlüssel für IAM-Benutzer im AWS Identity and Access Management-Benutzerhandbuch.
-
Mit dem Parameter Store angegebene Zeichenfolgen. Weitere Informationen finden Sie unter Systems Manager Parameter Store und in den Anleitungen zur Systems Manager Parameter Store-Konsole im Amazon EC2 Systems Manager Benutzerhandbuch.
-
Mit dem AWS Secrets Manager angegebene Zeichenfolgen. 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 Zuweisung vonkey
/value
Skalare, in denen jede Zuweisung eine einzelne benutzerdefinierte Umgebungsvariable im Klartext darstellt.key
ist der Name der benutzerdefinierten Umgebungsvariable undvalue
ist der Wert dieser Variablen.Wichtig Wir raten dringend davon ab, Umgebungsvariablen zum Speichern vertraulicher Werte zu verwenden, insbesondere des AWS-Zugriffsschlüssels und der geheimen Zugriffsschlüssel.IDs Umgebungsvariablen können mit Tools wie der CodeBuild-Konsole und über die AWS CLI im Klartext angezeigt werden. 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 für die interne 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 im Ausführen eines Build in 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 ist und Sie benutzerdefinierte Umgebungsvariablen abrufen möchten, die in Amazon EC2 Systems Manager Parameter Store gespeichert sind. Enthält eine Zuweisung vonkey
/value
Skalare, in denen jede Zuweisung 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 Umgebungsvariable, die im Amazon EC2 Systems Manager Parameter Store gespeichert ist. Informationen zum Speichern sensibler Werte finden Sie unter Systems Manager Parameter Store und Walkthrough:. Erstellen und Testen eines String-Parameters (Konsole) im -BenutzerhandbuchAmazon EC2 Systems Manager.Wichtig Um CodeBuild zu erlauben, benutzerdefinierte Umgebungsvariablen abzurufen, die in 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 im Erstellen Sie eine CodeBuild-Servicerolle.Alle Umgebungsvariablen, die Sie von Amazon EC2 Systems Manager Parameter Store abrufen, werden vorhandene Umgebungsvariablen ersetzen. 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 für die interne 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 im Ausführen eines Build in 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 AWS Secrets Manager gespeichert sind. 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 Umgebungsvariable. Verwenden Sie diesen Namen, um während des Builds auf die Variable zuzugreifen.
<secret-id>
-
(Erforderlich) Der Name oder Amazon-Ressourcenname (ARN), der als eindeutige Kennung für das Secret dient. Um auf ein Secret in Ihrem AWS-Konto zuzugreifen, geben Sie einfach den Secret-Namen an. Um auf ein Secret in einem anderen AWS-Konto zuzugreifen, geben Sie den ARN des Secrets an.
<json-key>
-
(Optional) Gibt den Schlüsselnamen des Secrets Manager-Schlüssel-Wert-Paares an, dessen Wert Sie abrufen möchten. Wenn Sie keinen
json-key
angeben, ruft CodeBuild den gesamten Secret-Text ab. <version-stage>
-
(Optional) Gibt die Secret-Version an, die Sie über die Staging-Bezeichnung abrufen möchten, die der Version zugeordnet ist. 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 ist
TestSecret
der Name des Schlüssel-Wert-Paares, das in Secrets Manager gespeichert ist. Der Schlüssel fürTestSecret
istMY_SECRET_VAR
. Sie greifen während des Builds mit demLOCAL_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 Variablen an, die Sie in einer separaten Zeile unter
exported-variables
exportieren möchten. 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.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 Store-Secrets, die im Build-Projekt angegeben sind.
-
Secrets Manager-Secrets, die im Build-Projekt angegeben sind.
-
Umgebungsvariablen, die mit
AWS_
beginnen.
-
- env/Git-Anmeldeinformationshelper
-
Optionale Zuweisung. Wird verwendet, um anzugeben, ob CodeBuild das Git-Hilfsprogramm für Anmeldeinformationen verwendet, um Git-Anmeldeinformationen bereitzustellen.
yes
, wenn 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 Ausführen von CodeBuild in einem expliziten Proxy-Server.
- 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. Legen Sie diese für Ihren Build in einem expliziten Proxy-Server auf
yes
fest, um CloudWatch Protokolle zu erstellen. Der Standardwert istno
.
phases
Erforderliche Sequenz. Steht für die Befehle CodeBuild wird während jeder Phase des Build ausgeführt.
In der Build-Spezifikationsversion 0.1 führt CodeBuild jeden Befehl in einer separaten Instance 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.
Die zulässigen Build-Phasennamen sind:
- phases/install
-
Optionale Sequenz. Steht für die Befehle, falls vorhanden, die CodeBuild während der Installation ausführt. Wir empfehlen Ihnen, die Phase
install
nur für Installationspakete in der Build-Umgebung einzusetzen. Sie können diese Phase beispielsweise verwenden, um ein Code-Testframework wie Mocha oder RSpec zu installieren.- phases/install/runtime-versions
-
Optionale Sequenz. Eine Laufzeitversion wird mit dem Ubuntu-Standardabbild 2.0 oder höher und dem Amazon Linux 2-Standardabbild 1.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 CodeBuild diese Hauptversion mit ihrer neuesten Unterversion verwendet, oderlatest
, um die neueste Haupt- und Unterversion zu verwenden (z. B.java: openjdk11
,ruby: 2.6
,nodejs: 12.x
oderjava: latest
). Sie können die Laufzeit unter Verwendung einer Zahl oder einer Umgebungsvariablen angeben. Wenn Sie beispielsweise das Amazon Linux 2-Standardabbild 2.0 verwenden, dann wird im Folgenden angegeben, dass Version 8 von Java, die neueste Unterversion von Python Version 3 und eine in einer Umgebungsvariablen von Ruby enthaltene Version installiert ist. Weitere Informationen finden Sie im Von bereitgestellte Docker-ImagesCodeBuild.phases: install: runtime-versions: java: corretto8 python: 3.x ruby: "$MY_RUBY_VAR"
You can specify one or more runtimes in the
runtime-versions
section of your buildspec file. If your runtime is dependent upon another runtime, you can also specify its dependent runtime in the buildspec file. If you do not specify any runtimes in the buildspec file, CodeBuild chooses the default runtimes that are available in the image you use. If you specify one or more runtimes, CodeBuild uses only those runtimes. If a dependent runtime is not specified, CodeBuild attempts to choose the dependent runtime for you.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.Die folgenden unterstützten Laufzeiten können angegeben werden.
Laufzeitversionen der Ubuntu- und Amazon Linux 2-PlattformLaufzeitname Version Spezifische Version Spezifische Haupt- und neueste Unterversion Aktuelle Version android 28
android: 28
android: 28.x
android: latest
29
android: 29
android: 29.x
dotnet 3.0
dotnet: 3.0
dotnet: 3.x
dotnet: latest
3.1
dotnet: 3.1
5.0 dotnet: 5.0
dotnet: 5.x
Golang 1.12
golang: 1.12
golang: 1.x
golang: latest
1.13
golang: 1.13
1.14
golang: 1.14
1.15 golang: 1.15
nodejs 8
nodejs: 8
nodejs: 8.x
nodejs: latest
10
nodejs: 10
nodejs: 10.x
12
nodejs: 12
nodejs: 12.x
14 nodejs: 14
nodejs: 14.x
Java openjdk8
java: openjdk8
java: openjdk8.x
java: latest
openjdk11
java: openjdk11
java: openjdk11.x
corretto8
java: corretto8
java: corretto8.x
corretto11
java: corretto11
java: corretto11.x
php 7.3
php: 7.3
php: 7.x
php: latest
7.4
php: 7.4
8.0 php: 8.0
php: 8.x
python 3.7
python: 3.7
python: 3.x
python: latest
3.8
python: 3.8
3.9 python: 3.9
ruby 2.6
ruby: 2.6
ruby: 2.x
ruby: latest
2.7
ruby: 2.7
Anmerkung If you specify a
runtime-versions
section and use an image other than Ubuntu Standard Image 2.0 or later, or the Amazon Linux 2 (AL2) standard image 1.0 or later, the build issues the warning, "Skipping install of runtimes. Runtime version selection is not supported by this build image
."
- phases/install/commands
-
commands
: Optionale Sequenz. Enthält eine Sequenz von Skalaren, wobei jeder Skalar für einen Einzelbefehl steht, der während der Installation von CodeBuild ausgeführt wird. CodeBuild führt jeden Befehl aus, jeweils einzeln, in der aufgeführten Reihenfolge, vom Anfang bis zum Ende.
- phases/install/finally
-
Optionaler Block. In einem
finally
-Block angegebene Befehle werden nach Befehlen imcommands
-Block ausgeführt. Die Befehle in einemfinally
-Block werden auch dann ausgeführt, wenn ein Befehl imcommands
-Block fehlschlägt. Wenn dercommands
-Block z. B. drei Befehle enthält und der erste fehlschlägt, überspringt CodeBuild die verbleibenden zwei Befehle und führt alle Befehle imfinally
-Block aus. 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.
- phases/pre_build
-
Optionale Sequenz. Steht für die Befehle, falls vorhanden, die CodeBuild vor dem Build ausführt. Beispielsweise könnten sie diese Phase nutzen, um sich bei Amazon ECR anzumelden, oder Sie könnten npm-Abhängigkeiten installieren.
- phases/pre_build/commands
-
Erforderliche Sequenz, wenn
pre_build
angegeben ist. Enthält eine Sequenz von Skalaren, wobei jeder Skalar für einen Einzelbefehl steht, den CodeBuild vor dem Build ausführt. CodeBuild führt jeden Befehl aus, jeweils einzeln, in der aufgeführten Reihenfolge, vom Anfang bis zum Ende.
- phases/pre_build/finally
-
Optionaler Block. In einem
finally
-Block angegebene Befehle werden nach Befehlen imcommands
-Block ausgeführt. Die Befehle in einemfinally
-Block werden auch dann ausgeführt, wenn ein Befehl imcommands
-Block fehlschlägt. Wenn dercommands
-Block z. B. drei Befehle enthält und der erste fehlschlägt, überspringt CodeBuild die verbleibenden zwei Befehle und führt alle Befehle imfinally
-Block aus. 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.
- phases/build
-
Optionale Sequenz. Steht für die Befehle, falls vorhanden, die CodeBuild während des Builds ausführt. Sie können diese Phase beispielsweise verwenden, um Mocha, RSpec oder sbt auszuführen.
- phases/build/commands
-
commands
: Erforderlich, wennbuild
angegeben ist. Enthält eine Sequenz von Skalaren, wobei jeder Skalar für einen Einzelbefehl steht, den CodeBuild während des Builds ausführt. CodeBuild führt jeden Befehl aus, jeweils einzeln, in der aufgeführten Reihenfolge, vom Anfang bis zum Ende.
- phases/build/finally
-
Optionaler Block. In einem
finally
-Block angegebene Befehle werden nach Befehlen imcommands
-Block ausgeführt. Die Befehle in einemfinally
-Block werden auch dann ausgeführt, wenn ein Befehl imcommands
-Block fehlschlägt. Wenn dercommands
-Block z. B. drei Befehle enthält und der erste fehlschlägt, überspringt CodeBuild die verbleibenden zwei Befehle und führt alle Befehle imfinally
-Block aus. 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.
- phases/post_build
-
Optionale Sequenz. Steht für die Befehle, falls vorhanden, die CodeBuild nach dem Build ausführt. Beispielsweise können Sie Maven nutzen, um die Build-Artefakte in eine Jar- oder WAR-Datei zu verpacken, oder Sie können ein Docker-Image in Amazon ECR verschieben. Dann können Sie eine Build-Benachrichtigung über Amazon SNS senden.
- phases/post_build/commands
-
commands
: Erforderlich, wennpost_build
angegeben ist. Enthält eine Sequenz von Skalaren, wobei jeder Skalar für einen Einzelbefehl steht, den CodeBuild nach dem Build ausführt. CodeBuild führt jeden Befehl aus, jeweils einzeln, in der aufgeführten Reihenfolge, vom Anfang bis zum Ende.
- phases/post_build/finally
-
Optionaler Block. In einem
finally
-Block angegebene Befehle werden nach Befehlen imcommands
-Block ausgeführt. Die Befehle in einemfinally
-Block werden auch dann ausgeführt, wenn ein Befehl imcommands
-Block fehlschlägt. Wenn dercommands
-Block z. B. drei Befehle enthält und der erste fehlschlägt, überspringt CodeBuild die verbleibenden zwei Befehle und führt alle Befehle imfinally
-Block aus. 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.
In einigen Build-Phasen können Befehle nicht ausgeführt werden, wenn Befehle in früheren
Build-Phasen fehlschlagen. Wenn ein Befehl beispielsweise während der Phase install
fehlschlägt, wird keiner der Befehle in den Phasen pre_build
, build
, und post_build
für diesen Build-Lebenszyklus ausgeführt. Weitere Informationen finden Sie im Übergang von Build-Phasen.
reports
- 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 ARN für eine vorhandene Berichtsgruppe oder den Namen einer neuen Berichtsgruppe an. Wenn Sie einen Namen angeben, erstellt CodeBuild eine Berichtsgruppe mit Ihrem Projektnamen und dem Namen, den Sie im Format
<project-name>-<report-group-name>
angeben. 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 Sequenz von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem CodeBuild Testdateien in Bezug auf den ursprünglichen Build-Speicherort oder, falls festgelegt, den
base-directory
finden kann. Speicherorte können Folgendes umfassen:-
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. -
stellt alle Dateien in einem Unterverzeichnis mit dem Namen dar.my-subdirectory
/*my-subdirectory
. -
stellt alle Dateien dar, 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
Code-Abdeckungsberichte
-
CLOVERXML
-
Clover-XML
-
COBERTURAXML
-
Cobertura-XML
-
JACOCOXML
-
JaCoCo-XML
-
SIMPLECOV
-
SimpleCov-JSON
Anmerkung CodeBuild akzeptiert JSON-Codeabdeckungsberichte, die von simplecov
generiert wurden, nicht jedoch von simplecov-json .
-
- reports/<report-group>/base-directory
-
Optionale Zuweisung. Stellt ein oder mehrere Verzeichnisse der obersten Ebene in Bezug auf den ursprünglichen Build-Speicherort dar, mit denen CodeBuild ermittelt, wo die rohen Testdateien gefunden werden sollen.
- 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.
artifacts
Optionale Sequenz. Gibt an, wo CodeBuild die Build-Ausgabe finden kann und wie CodeBuild diese auf den Upload zum S3-Ausgabe-Bucket vorbereitet. Diese Sequenz ist nicht erforderlich, wenn Sie beispielsweise ein Docker-Image erstellen und dies zu Amazon ECR verschieben, oder wenn Sie Einheitentests auf Ihrem Quellcode ausführen, dies jedoch nicht erstellen.
- artifacts/files
-
Erforderliche Sequenz. Diese stellt die Speicherorte dar, die die Build-Ausgabeartefakte in der Build-Umgebung enthalten. Enthält eine Sequenz von Skalaren, wobei jeder Skalar für einen einzelnen Speicherort steht, an dem CodeBuild Build-Ausgabeartefakte in Bezug auf die ursprünglichen Build-Speicherorte finden kann, oder, sofern festgelegt, auf das 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. -
repräsentiert alle Dateien in einem Unterverzeichnis mit dem Namenmy-subdirectory
/*my-subdirectory
. -
steht für alle Dateien, beginnend rekursiv mit einem Unterverzeichnis mit dem Namenmy-subdirectory
/**/*my-subdirectory
.
Wenn Sie Speicherorte von Build-Ausgabeartefakten angeben, kann CodeBuild die ursprünglichen Build-Speicherorte in der Build-Umgebung lokalisieren. 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 die CodeBuild-API zum Erstellen Ihrer Builds und das
overrideArtifactName
-Flag ist für dasProjectArtifacts
-Objekt gesetzt, wenn ein Projekt aktualisiert wird, ein Projekt erstellt wird 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 beim Erstellen oder Aktualisieren eines Projekts Enable semantic versioning (Semantisches Versioning aktivieren) aus. 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 Artefakt-Namen, der eine CodeBuild-Umgebungsvariable verwendet. 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 Artefakt-Namen, der eine CodeBuild-Umgebungsvariable verwendet, wobei das Erstellungsdatum des Artefakts angefügt ist.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: $AWS_REGION-$(date +%Y-%m-%d)
-
- 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 eines oder mehrere der Top-Level-Verzeichnisse bezogen auf den ursprünglichen Speicherort des Build dar, den CodeBuild verwendet, um zu ermitteln, welche Dateien und Unterverzeichnisse in den Build-Ausgabeartefakt aufgenommen werden. 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
-
- 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/files Sequenz 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. Gibt an, wo CodeBuild die Dateien für den Cache-Upload zu einem
S3-Cache-Bucket vorbereiten kann. 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 Sequenz von Skalaren, wobei jeder Skalar für einen einzelnen Speicherort steht, an dem CodeBuild Build-Ausgabeartefakte in Bezug auf die ursprünglichen Build-Speicherorte finden kann, oder, sofern festgelegt, auf das 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. -
stellt alle Dateien in einem Unterverzeichnis mit dem Namen dar.my-subdirectory
/*my-subdirectory
. -
stellt alle Dateien dar, beginnend mit einem Unterverzeichnis mit dem Namenmy-subdirectory
/**/*my-subdirectory
.
-
Da es sich bei der Build-Spezifikationsdeklaration um eine gültige YAML handelt, ist die Formatierung in einer Build-Spezifikationsdeklaration wichtig. Wenn die Anzahl der Leerzeichen in der Build-Spezifikationsdeklaration unzulässig ist, können die Builds sofort fehlschlagen. Verwenden Sie eine YAML-Validierung, um zu testen, ob es sich bei Ihrer Build-Spezifikationsdeklaration um eine gültige YAML handelt.
Wenn Sie die AWS CLI oder die AWS SDKs verwenden, um eine Build-Spezifikation beim Erstellen oder Aktualisieren eines Build-Projekts zu deklarieren, muss die Build-Spezifikation eine einzelne Zeichenfolge im YAML-Format sein, zusammen mit erforderlichen Escape-Zeichen für Leerzeichen und neue Zeilen. Es folgt ein Beispiel im nächsten Abschnitt.
Wenn Sie die CodeBuild- oder AWS CodePipeline-Konsolen anstelle einer Datei buildspec.yml
verwenden, können Sie ausschließlich Befehle für die build
-Phase einfügen. 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 CodeBuild- oder CodePipeline-Konsolen statt einer Datei buildspec.yml
einsetzen, um die Speicherorte der Build-Ausgabeartefakte in der Build-Umgebung 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 sehen Sie ein Beispiel der vorherigen Build-Spezifikation, ausgedrückt als einzelne Zeichenfolge, zur Verwendung mit der AWS CLI oder der 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 sehen Sie ein Beispiel für die Befehle in der Phase build
für die Nutzung mit CodeBuild- oder CodePipeline-Konsolen.
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. -
Eine benutzerdefinierte, in Amazon EC2 Systems Manager Parameter Store gespeicherte Umgebungsvariable mit der Bezeichnung
dockerLoginPassword
, auf die später in Build-Befehlen mit dem SchlüsselLOGIN_PASSWORD
verwiesen wird. -
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 andere Aktionen durchzuführen, wie z. B. das Build-Ausgabeartefakt in seinem internen Repository zu installieren),docker login
(um sich mit dem Passwort, das dem Wert der benutzerdefinierten UmgebungsvariablendockerLoginPassword
entspricht, die Sie in Amazon EC2 Systems Manager Parameter Store festgelegt haben, in Docker anzumelden) und einigeecho
-Befehle. Die Befehleecho
wurden hier aufgenommen, um zu zeigen, wie und in welcher Reihenfolge CodeBuild Befehle ausführt. -
files
stellt die Dateien dar, die in den Build-Ausgabespeicherort hochgeladen werden sollen. In diesem Beispiel lädt CodeBuild die einzelne DateimessageUtil-1.0.jar
hoch. Die DateimessageUtil-1.0.jar
befindet sich im relativen Verzeichnis mit dem Namentarget
in der Build-Umgebung. 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 den 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. Die vom Test-Framework generierten Testergebnisse 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. |