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. # Spezifikationsreferenz erstellen 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 im YAML-Format, die zur Ausführung eines Builds CodeBuild verwendet wird. Sie können eine Buildspec als Teil des Quellcodes hinzufügen 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](concepts.md#concepts-how-it-works). **Topics** + [Dateiname der Build-Spezifikation und Speicherort](#build-spec-ref-name-storage) + [Syntax der Build-Spezifikation](#build-spec-ref-syntax) + [Beispiel für eine Build-Spezifikation](#build-spec-ref-example) + [Versionen der Build-Spezifikationen](#build-spec-ref-versions) + [Buildspec-Referenz für Batch-Builds](batch-build-buildspec.md) ## 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` und `buildspec_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 ihrem ARN an (z. B. `arn:aws:s3:::{{}}/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 CLI `create-project` or aus und setzen Sie den `buildspec` Wert auf den Pfad zur alternativen Buildspec-Datei relativ zum Wert der integrierten Umgebungsvariablen. `CODEBUILD_SRC_DIR` Das Gleiche können Sie auch mit der `create project` Operation in den SDKs tun. AWS Für weitere Informationen siehe [Erstellen eines Build-Projekts](create-project.md) oder [Ändern Sie die Einstellungen für das Build-Projekt](change-project.md). + Führen Sie den AWS CLI `start-build` Befehl aus und setzen Sie den `buildspecOverride` Wert auf den Pfad zur alternativen Buildspec-Datei relativ zum Wert der integrierten Umgebungsvariablen. `CODEBUILD_SRC_DIR` Das Gleiche können Sie auch mit der `start build` Operation in den SDKs tun. AWS Weitere Informationen finden Sie unter [Führen Sie Builds manuell aus](run-build.md). + Setzen Sie in einer AWS CloudFormation Vorlage die `BuildSpec` Eigenschaft von `Source` in einer Ressource vom Typ `AWS::CodeBuild::Project` auf den Pfad zur alternativen Buildspec-Datei relativ zum Wert der integrierten Umgebungsvariablen. `CODEBUILD_SRC_DIR` Weitere Informationen finden Sie unter der BuildSpec Eigenschaft in der [AWS CodeBuild Projektquelle ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-source.html) im *AWS CloudFormation Benutzerhandbuch. * ## Syntax der Build-Spezifikation Build-Spezifikationsdateien müssen im Format [YAML](http://yaml.org/) ausgedrückt werden. 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: # build-fanout: phases: install: run-as: {{Linux-user-name}} on-failure: ABORT | CONTINUE | RETRY | RETRY-{{count}} | RETRY-{{regex}} | RETRY-{{count}}-{{regex}} runtime-versions: {{runtime}}: {{version}} {{runtime}}: {{version}} commands: - {{command}} - {{command}} finally: - {{command}} - {{command}} pre\_build: run-as: {{Linux-user-name}} on-failure: ABORT | CONTINUE | RETRY | RETRY-{{count}} | RETRY-{{regex}} | RETRY-{{count}}-{{regex}} commands: - {{command}} - {{command}} finally: - {{command}} - {{command}} build: run-as: {{Linux-user-name}} on-failure: ABORT | CONTINUE | RETRY | RETRY-{{count}} | RETRY-{{regex}} | RETRY-{{count}}-{{regex}} commands: - {{command}} - {{command}} finally: - {{command}} - {{command}} post\_build: run-as: {{Linux-user-name}} on-failure: ABORT | CONTINUE | RETRY | RETRY-{{count}} | RETRY-{{regex}} | RETRY-{{count}}-{{regex}} 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: key: {{key}} fallback-keys: - {{fallback-key}} - {{fallback-key}} action: restore | save 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](#build-spec-ref-versions). ### 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** Zum Schutz vertraulicher Informationen sind die folgenden Informationen in den CodeBuild Protokollen versteckt: AWS Zugriffsschlüssel-IDs. Weitere Informationen finden Sie [ im Benutzerhandbuch unter ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) *Verwalten von Zugriffsschlüsseln für *AWS Identity and Access Management IAM-Benutzer. Mit dem Parameter Store angegebene Zeichenfolgen. Weitere Informationen finden Sie unter [ Systems Manager Parameter Store ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) und Walkthrough [ Systems Manager Parameter Store Console ](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console) im * Amazon EC2 Systems Manager-Benutzerhandbuch. * Zeichenfolgen, die mit angegeben wurden. AWS Secrets Manager Weitere Informationen finden Sie unter [Schlüsselverwaltung](security-key-management.md). **Anmerkung** Die Maskierung entspricht exakt dem Wert, der im Amazon EC2 Systems Manager Parameter Store oder gespeichert ist. AWS Secrets Manager Wenn ein Build-Befehl ein Geheimnis transformiert, bevor es in den Protokollen erscheint, ist das Ergebnis eine andere Zeichenfolge, die nicht maskiert ist. Wenn Sie es beispielsweise mit Base64 kodieren, es umkehren, die Groß- und Kleinschreibung ändern oder es mit anderem Text verketten, entsteht ein anderer Wert, der in den Build-Protokollen erscheinen kann. Um einen Wert maskiert zu halten, speichern Sie ihn in der Form, die Ihr Build verwendet. Wenn Ihr Build beispielsweise einen Base64-encoded Wert erfordert, speichern Sie die Base64-encoded Zeichenfolge direkt in unserem AWS Secrets Manager Amazon EC2 Systems Manager Parameter Store. Auf diese Weise entspricht der protokollierte Wert dem gespeicherten Wert. 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 von {{key}} {{value}} /-Skalaren, wobei jede Zuordnung eine einzelne benutzerdefinierte Umgebungsvariable im Klartext darstellt. {{key}}ist der Name der benutzerdefinierten Umgebungsvariablen und der {{value}} Wert dieser Variablen. Wir raten dringend davon ab, vertrauliche Werte in Umgebungsvariablen zu speichern. Umgebungsvariablen können mithilfe von Tools wie der CodeBuild Konsole und dem im Klartext angezeigt werden. AWS CLI Für vertrauliche Werte sollte stattdessen die Zuweisung per `parameter-store` oder `secrets-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 von `my_value` enthält und Sie eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `other_value` festlegen, wird `my_value` durch `other_value` ersetzt. Wenn das Docker-Image demgegenüber bereits eine Umgebungsvariable mit dem Namen `PATH` und einem Wert von `/usr/local/sbin:/usr/local/bin` enthält und Sie eine Umgebungsvariable mit dem Namen `PATH` 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 [Manuelles Ausführen von AWS CodeBuild Builds](run-build.md). + Der Wert in der Build-Projektdefinition folgt darauf. Beim Erstellen oder Bearbeiten eines Projekts können Sie Umgebungsvariablen auf Projektebene hinzufügen. Weitere Informationen erhalten Sie unter [Erstellen Sie ein Build-Projekt in AWS CodeBuild](create-project.md) und [Ändern Sie die Build-Projekteinstellungen in AWS CodeBuild](change-project.md). + 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 von {{key}} {{value}} /-Skalaren, 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, und {{value}} ist der Name der benutzerdefinierten Umgebungsvariablen, die im Amazon EC2 Systems Manager Parameter Store gespeichert ist. Informationen zum Speichern vertraulicher Werte finden Sie unter [ Systems Manager-Parameterspeicher ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) und [ exemplarische Vorgehensweise: Erstellen und testen Sie einen String-Parameter (Konsole) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-console.html) im * Amazon EC2 Systems Manager-Benutzerhandbuch. * Um das Abrufen benutzerdefinierter 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 [Erlauben CodeBuild Sie die Interaktion mit anderen AWS service](setting-up-service-role.md). Alle Umgebungsvariablen, die Sie aus dem Amazon EC2 Systems Manager Parameter Store abrufen, ersetzen vorhandene Umgebungsvariablen. Wenn das Docker-Image beispielsweise bereits eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `my_value` enthält und Sie eine Umgebungsvariable mit dem Namen `MY_VAR` und einem Wert von `other_value` abrufen, wird `my_value` durch `other_value` ersetzt. Wenn das Docker-Image demgegenüber bereits eine Umgebungsvariable mit dem Namen `PATH` und einem Wert von `/usr/local/sbin:/usr/local/bin` enthält und Sie eine Umgebungsvariable mit dem Namen `PATH` 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 [Manuelles Ausführen von AWS CodeBuild Builds](run-build.md). + Der Wert in der Build-Projektdefinition folgt darauf. Beim Erstellen oder Bearbeiten eines Projekts können Sie Umgebungsvariablen auf Projektebene hinzufügen. Weitere Informationen erhalten Sie unter [Erstellen Sie ein Build-Projekt in AWS CodeBuild](create-project.md) und [Ändern Sie die Build-Projekteinstellungen in AWS CodeBuild](change-project.md). + 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` nach dem folgenden Muster an: `{{}}`: `{{}}:{{}}:{{}}:{{}}` {{}} (Erforderlich) Der Name der lokalen Umgebungsvariablen. Verwenden Sie diesen Namen, um während des Builds auf die Variable zuzugreifen. {{}} (Erforderlich) Der Name oder 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 die geheime ARN an. {{}} (Optional) Gibt den Schlüsselnamen des Secrets Manager-Schlüssel-Wert-Paares an, dessen Wert Sie abrufen möchten. Wenn Sie keinen angeben`json-key`, wird der gesamte CodeBuild geheime Text abgerufen. {{}} (Optional) Gibt die geheime Version, die Sie abrufen möchten, anhand des Staging-Labels an, das 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 Sie `version-id` nicht an. Wenn Sie keine Versionsstufe oder Versions-ID angeben, wird standardmäßig die Version mit dem Versionsstufenwert `AWSCURRENT` abgerufen. {{}} (Optional) Gibt den eindeutigen Bezeichner der Version des Secrets an, das Sie verwenden möchten. Wenn Sie `version-id` angeben, dürfen Sie `version-stage` nicht angeben. Wenn Sie keine Versionsstufe oder Versions-ID angeben, wird standardmäßig die Version mit dem Versionsstufenwert `AWSCURRENT` abgerufen. Im folgenden Beispiel `TestSecret` ist das der Name des Schlüssel-Wert-Paares, das in Secrets Manager gespeichert ist. Der Schlüssel für `TestSecret` ist. `MY_SECRET_VAR` Sie greifen während des Builds mit dem `LOCAL_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?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 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 zusammen mit verwendet AWS CodePipeline , um Umgebungsvariablen aus der aktuellen Build-Phase in nachfolgende Phasen der Pipeline zu exportieren. Weitere Informationen finden Sie [ im *AWS CodePipeline Benutzerhandbuch unter*](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-variables.html) Arbeiten mit Variablen. Während eines Builds ist der Wert einer Variablen ab der `install`-Phase verfügbar. Er kann zwischen dem Beginn der `install`-Phase und dem Ende der `post_build`-Phase aktualisiert werden. Nach dem Ende der `post_build`-Phase kann sich der Wert der exportierten Variablen nicht ändern. Folgendes kann nicht exportiert werden: + Amazon EC2 Systems Manager Parameter Store Secrets, die im Build-Projekt angegeben sind. + Secrets Manager-Geheimnisse, die im Build-Projekt angegeben wurden + Umgebungsvariablen, die mit `AWS_` beginnen. env/git-credentials ** ** Optionale Zuweisung. Wird verwendet, um anzugeben, ob der Git-Anmeldeinformationen-Helper zur Bereitstellung von Git-Anmeldeinformationen CodeBuild verwendet wird. `yes`wenn es verwendet wird. Andernfalls `no` oder nicht angegeben. Weitere Informationen finden Sie unter [gitcredentials](https://git-scm.com/docs/gitcredentials) auf der Git-Website. `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](run-codebuild-in-explicit-proxy-server.md). proxy/**upload-artifacts** Optionale Zuweisung. Legen Sie diese auf `yes` fest, wenn Ihr Build in einem expliziten Proxy-Server Artefakte hochladen soll. Der Standardwert ist `no`. proxy/**logs** Optionale Zuweisung. Setzen Sie auf `yes` für Ihren Build einen expliziten Proxyserver, um CloudWatch Protokolle zu erstellen. Der Standardwert ist `no`. ### phases Erforderliche Sequenz. Stellt die Befehle dar, die in jeder Phase des Builds CodeBuild ausgeführt werden. **Anmerkung** In Buildspec Version 0.1 CodeBuild wird jeder Befehl in einer separaten Instanz der Standard-Shell in der Build-Umgebung ausgeführt. 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](build-env-ref-cmd.md). 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. Wenn beispielsweise global und für die `install` Phase nur eine `run-as` Anweisung `run-as` spezifiziert User-1 User-2, dann werden alle Befehle in der Buildspec-Datei als ausgeführt, User-1 * mit Ausnahme der * Befehle in der `install` Phase, die als ausgeführt werden. User-2 phasen/\*/ bei Ausfall ** ** 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. + `RETRY`- Wiederholen Sie den Build bis zu dreimal mit einer Fehlermeldung, die dem regulären Ausdruck `.*` entspricht. + `RETRY-{{count}}`— Wiederholen Sie den Build eine bestimmte Anzahl von Malen, wie durch {{count}} eine Fehlermeldung dargestellt, die dem regulären Ausdruck entspricht. `.*` Beachten Sie, dass dieser Wert zwischen 0 und 100 liegen {{count}} muss. Zu den gültigen Werten gehören beispielsweise `RETRY-4` und`RETRY-8`. + `RETRY-{{regex}}`- Wiederholen Sie den Build bis zu dreimal und verwenden Sie ihn, {{regex}} um einen regulären Ausdruck einzufügen, der einer bestimmten Fehlermeldung entspricht. Gültige Werte sind beispielsweise `Retry-.*Error: Unable to connect to database.*` und`RETRY-invalid+`. + `RETRY-{{count}}-{{regex}}`— Wiederholen Sie den Build eine bestimmte Anzahl von Malen, wie durch {{count}} dargestellt. Beachten Sie, dass dieser Wert zwischen 0 und 100 liegen {{count}} muss. Sie können es auch verwenden{{regex}}, um einen regulären Ausdruck einzufügen, der der Fehlermeldung entspricht. Zu den gültigen Werten gehören beispielsweise `Retry-3-.*connection timed out.*` und`RETRY-8-invalid+`. Wenn diese Eigenschaft nicht angegeben ist, folgt der Fehlerprozess den Übergangsphasen, wie unter beschrieben[Übergang von Build-Phasen](view-build-details-phases.md). Das `on-failure` Attribut wird nicht unterstützt, wenn Lambda-Rechenleistung oder reservierte Kapazität verwendet wird. Dieses Attribut funktioniert nur mit EC2-Compute-Images, die von bereitgestellt werden. CodeBuild phasen/\*/ endlich ** ** Optionaler Block. In einem `finally` Block angegebene Befehle werden nach Befehlen im Block ausgeführt. `commands` Die Befehle in einem `finally` Block werden auch dann ausgeführt, wenn ein Befehl im `commands` Block fehlschlägt. Wenn der `commands` Block beispielsweise drei Befehle enthält und der erste fehlschlägt, werden die verbleibenden zwei Befehle CodeBuild übersprungen und alle Befehle im `finally` Block ausgeführt. Die Phase ist erfolgreich, wenn alle Befehle in den Blöcken `commands` und `finally` 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. Beispielsweise könnten sie diese Phase nutzen, um ein Code-Testframework wie Mocha oder RSpec zu installieren. phases/install/**Laufzeitversionen ** 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 an, die eine bestimmte Version CodeBuild verwendet, gefolgt von einer Hauptversion, `.x` um anzugeben, dass diese Hauptversion mit ihrer neuesten Nebenversion verwendet wird, oder `latest` um die neueste Haupt- und Nebenversion zu verwenden (z. B.`ruby: 3.2`,`nodejs: 18.x`, oder`java: 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](build-env-ref-available.md). ``` 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, wählen Sie die Standardlaufzeiten CodeBuild aus, 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 keine Laufzeitversion angegeben ist, wird die Standardversion CodeBuild verwendet. Die Standardversion kann sich ändern, wenn eine frühere Standardversion das Ende ihrer Lebensdauer (EOL) erreicht. Um unerwartete Änderungen an der Build-Umgebung zu vermeiden, empfehlen wir, eine Laufzeitversion in der Buildspec-Datei anzugeben. Wenn zwei angegebene Laufzeiten unvereinbar sind, schlägt der Build fehl. Beispiel: `android: 29` und `java: openjdk11` sind miteinander unvereinbar. Wenn beide angegeben werden, schlägt der Build fehl. Weitere Hinweise zu den verfügbaren Laufzeiten finden Sie unter. [Verfügbare Laufzeiten](available-runtimes.md) 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 "`Skipping install of runtimes. Runtime version selection is not supported by this build image`aus.“ phases/install/Befehle ** ** Optionale Sequenz. Enthält eine Folge von Skalaren, wobei jeder Skalar einen einzelnen Befehl darstellt, 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 ECR anzumelden, oder Sie könnten npm-Abhängigkeiten installieren. phases/pre\_build/Befehle ** ** Erforderliche Sequenz, wenn `pre_build` angegeben ist. Enthält eine Folge von Skalaren, wobei jeder Skalar einen einzelnen Befehl darstellt, der vor dem CodeBuild Build 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. Beispielsweise könnten sie diese Phase nutzen, um Mocha, RSpec oder sbt auszuführen. phases/build/**Befehle ** Erforderlich, `build` wenn angegeben. Enthält eine Folge von Skalaren, wobei jeder Skalar einen einzelnen Befehl darstellt, 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, falls vorhanden, die nach dem Build CodeBuild ausgeführt werden. Sie könnten beispielsweise Maven verwenden, um die Build-Artefakte in eine JAR- oder WAR-Datei zu packen, oder Sie könnten ein Docker-Image in Amazon ECR übertragen. Dann könnten Sie eine Build-Benachrichtigung über Amazon SNS senden. phases/post\_build/Befehle ** ** Erforderlich, `post_build` wenn angegeben. Enthält eine Folge von Skalaren, wobei jeder Skalar einen einzelnen Befehl darstellt, 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 ARN für eine vorhandene Berichtsgruppe oder den Namen einer neuen Berichtsgruppe an. Wenn Sie einen Namen angeben, CodeBuild erstellt eine Berichtsgruppe unter Verwendung Ihres Projektnamens und des Namens, den Sie im Format angeben`-`. 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](test-report-group-naming.md). reports//**files** Erforderliche Sequenz. Stellt die Speicherorte dar, die die Rohdaten der vom Bericht generierten Testergebnisse enthalten. Enthält eine Abfolge von Skalaren, wobei jeder Skalar einen separaten Ort darstellt, an dem Testdateien gefunden CodeBuild werden können, relativ zum ursprünglichen Build-Speicherort oder, falls gesetzt, zum. `base-directory` Speicherorte können Folgendes enthalten: + Eine Einzeldatei (z. B. `my-test-report-file.json`). + Eine einzelne Datei in einem Unterverzeichnis (Beispiel: `{{my-subdirectory}}/my-test-report-file.json` oder `{{my-parent-subdirectory}}/{{my-subdirectory}}/my-test-report-file.json`). + `'**/*'` steht rekursiv für alle Dateien. + `{{my-subdirectory}}/*`steht für alle Dateien in einem Unterverzeichnis mit dem Namen. {{my-subdirectory}} + `{{my-subdirectory}}/**/*`steht rekursiv für alle Dateien, die von einem Unterverzeichnis mit dem Namen ausgehen. {{my-subdirectory}} reports//**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` Cucumber JSON `JUNITXML` JUnit XML `NUNITXML` NUnit XML `NUNIT3XML` NUnit 3 XML `TESTNGXML` TestNG XML `VISUALSTUDIOTRX` Visual Studio TRX **Code-Abdeckungsberichte** `CLOVERXML` Clover XML `COBERTURAXML` Cobertura XML `JACOCOXML` JaCoCo XML `SIMPLECOV` SimpleCov JSON CodeBuild akzeptiert JSON-Codeabdeckungsberichte, die von [ simplecov generiert wurden](https://github.com/simplecov-ruby/simplecov), nicht von simplecov-json. [https://github.com/vicentllongo/simplecov-json](https://github.com/vicentllongo/simplecov-json) reports//**base-directory** Optionale Zuweisung. Stellt ein oder mehrere Verzeichnisse der obersten Ebene relativ zum ursprünglichen Build-Speicherort dar, anhand dessen bestimmt wird, wo die CodeBuild Rohtestdateien zu finden sind. reports//**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 dies `yes` enthält, werden alle Testdateien im selben Ausgabeverzeichnis abgelegt. Wenn beispielsweise ein Pfad zu einem Testergebnis `com/myapp/mytests/TestResult.xml` lautet, wird die Datei durch Angabe von `yes` 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 Sequenz 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 mit `x-amz-meta-codebuild-buildarn` dem Namen, der den `buildArn` des CodeBuild Builds enthält, der Artefakte in Amazon S3 veröffentlicht. Der `buildArn` wird hinzugefügt, um die Quellverfolgung 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 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: `{{my-subdirectory}}/my-file.jar` oder `{{my-parent-subdirectory}}/{{my-subdirectory}}/my-file.jar`). + `'**/*'` steht rekursiv für alle Dateien. + `{{my-subdirectory}}/*`steht für alle Dateien in einem Unterverzeichnis mit dem Namen. {{my-subdirectory}} + `{{my-subdirectory}}/**/*`steht rekursiv für alle Dateien, die von einem Unterverzeichnis mit dem Namen ausgehen. {{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 wie `echo $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, um Ihre Builds zu erstellen, und das `overrideArtifactName` Flag wird für das `ProjectArtifacts` Objekt gesetzt, wenn ein Projekt aktualisiert, ein Projekt erstellt oder ein Build gestartet wird. + Sie verwenden die CodeBuild Konsole, um Ihre Builds zu erstellen, ein Name wird in der Buildspec-Datei 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)](create-project.md#create-project-console). 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](http://pubs.opengroup.org/onlinepubs/9699919799/). + 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](build-env-ref-env-vars.md). ``` 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 ist. ``` 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 in Verzeichnissen platziert werden, die auf dem Pfad im Namen basieren. In diesem Beispiel werden Build-Artefakte in der Ausgabe unter platziert`builds//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. Wenn `yes`enthalten ist, werden alle Build-Artefakte im selben Ausgabeverzeichnis platziert. Wenn beispielsweise ein Pfad zu einer Datei im Build-Ausgabeartefakt `com/mycompany/app/HelloWorld.java` ist, wird diese Datei durch Angabe von `yes` in `/HelloWorld.java` gespeichert. artifacts/**base-directory** Optionale Zuweisung. Stellt ein oder mehrere Verzeichnisse der obersten Ebene relativ zum ursprünglichen Build-Speicherort dar, anhand dessen bestimmt wird, welche Dateien und Unterverzeichnisse in das CodeBuild 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 mit `my-directory` beginnen. Die übereinstimmenden Top-Level-Verzeichnisse werden nicht in den Build-Ausgabeartefakt aufgenommen, sondern nur deren Dateien und Unterverzeichnisse. Sie können `files` und `discard-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/Pfade ausschließen ** ** Optionale Zuweisung. Steht für einen oder mehrere Pfade, relativ zu `base-directory` denen, die Artefakte aus dem Build ausgeschlossen CodeBuild werden. 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/enable-Symlinks ** Optional. Wenn der Ausgabetyp ist`ZIP`, gibt an, ob interne symbolische Links in der ZIP-Datei erhalten bleiben. Wenn dies den Wert enthält`yes`, werden alle internen symbolischen Links in der Quelle in der ZIP-Datei für die Artefakte beibehalten. Artefakte/s3-Präfix ** ** Optional. Gibt ein Präfix an, das verwendet wird, wenn die Artefakte in einen Amazon S3-Bucket ausgegeben werden, und der Namespace-Typ ist. `BUILD_ID` Wenn es verwendet wird, lautet `//.zip` der Ausgabepfad im Bucket. artifacts/**secondary-artifacts** Optionale Sequenz. Repräsentiert einzelne oder mehrere Artefaktdefinitionen als Zuordnung zwischen einem Artefaktbezeichner und einer Artefaktdefinition. Jede Artefakt-ID in diesem Block muss mit einem Artefakt übereinstimmen, das im `secondaryArtifacts` Attribut Ihres Projekts definiert ist. Jede separate Definition hat die gleiche Syntax wie der `artifacts`-Block oben. Die [`artifacts/files`](#build-spec.artifacts.files) Reihenfolge 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": "{{}}", "artifactIdentifier": "artifact1", "name": "secondary-artifact-name-1" }, { "type": "S3", "location": "{{}}", "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/Schlüssel ** ** Optionale Sequenz. Stellt den Primärschlüssel dar, der beim Suchen oder Wiederherstellen eines Caches verwendet wird. CodeBuild entspricht exakt dem Primärschlüssel. Hier ist ein Beispiel für den Schlüssel: ``` key: npm-key-$(codebuild-hash-files package-lock.json) } ``` Cache/Fallback-Schlüssel ** ** Optionale Sequenz. Stellt eine Liste von Ersatzschlüsseln dar, die nacheinander verwendet werden, wenn mithilfe des Primärschlüssels kein Cache gefunden werden kann. Bis zu fünf Ersatzschlüssel werden unterstützt, und jeder Schlüssel wird mithilfe einer Präfixsuche abgeglichen. Diese Sequenz wird ignoriert, wenn der ** Schlüssel nicht angegeben ** wird. Hier ist ein Beispiel für die Fallback-Schlüssel: ``` fallback-keys: - npm-key-$(codebuild-hash-files package-lock.json) } - npm-key- - npm- ``` Cache/Aktion ** ** Optionale Sequenz. Gibt die Aktion an, die im Cache ausgeführt werden soll. Gültige Werte sind: + `restore`wodurch nur der Cache wiederhergestellt wird, ohne Updates zu speichern. + `save`was nur den Cache speichert, ohne eine frühere Version wiederherzustellen. Wenn kein Wert angegeben wird, wird CodeBuild standardmäßig sowohl das Wiederherstellen als auch das Speichern ausgeführt. cache/**paths** Erforderliche Sequenz. Steht für die Speicherorte des Caches. Enthält eine Folge von Skalaren, wobei jeder Skalar einen separaten Ort darstellt, an dem Artefakte für die Build-Ausgabe gefunden werden CodeBuild können, relativ zum ursprünglichen Build-Speicherort oder, falls gesetzt, zum Basisverzeichnis. Speicherorte können Folgendes enthalten: + Eine Einzeldatei (z. B. `my-file.jar`). + Eine einzelne Datei in einem Unterverzeichnis (Beispiel: `{{my-subdirectory}}/my-file.jar` oder `{{my-parent-subdirectory}}/{{my-subdirectory}}/my-file.jar`). + `'**/*'` steht rekursiv für alle Dateien. + `{{my-subdirectory}}/*`steht für alle Dateien in einem Unterverzeichnis mit dem Namen. {{my-subdirectory}} + `{{my-subdirectory}}/**/*`steht rekursiv für alle Dateien, die von einem Unterverzeichnis mit dem Namen ausgehen. {{my-subdirectory}} **Wichtig** 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 beim Erstellen oder Aktualisieren eines Build-Projekts die oder die AWS SDKs verwenden AWS CLI, um eine Buildspec zu deklarieren, muss die Buildspec eine einzelne Zeichenfolge im YAML-Format sein, zusammen mit den erforderlichen Leerzeichen und Escapezeichen für Zeilenumbrüche. Es folgt ein Beispiel im nächsten Abschnitt. Wenn Sie statt einer CodeBuild buildspec.yml-Datei die oder AWS CodePipeline console verwenden, können Sie nur Befehle 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 CodeBuild oder CodePipeline console anstelle einer buildspec.yml-Datei verwenden, 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 ist ein Beispiel für die vorangegangene Buildspec, ausgedrückt als einzelne Zeichenfolge, zur Verwendung mit den, oder den SDKs. AWS CLI AWS ``` "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 oder Konsolen. CodeBuild 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, den `dockerLoginPassword` Sie im Amazon EC2 Systems Manager Parameter Store gespeichert haben, wird später in Build-Befehlen mithilfe des Schlüssels `LOGIN_PASSWORD` verwiesen. + Sie können diese Build-Phasennamen nicht ändern. Die Befehle, die in diesem Beispiel ausgeführt werden, sind `apt-get update -y` und `apt-get install -y maven` (um Apache Maven zu installieren), `mvn install` (um den Quellcode zu kompilieren, zu testen und in ein Build-Ausgabe-Artefakt zu packen und um das Build-Ausgabe-Artefakt in seinem internen Repository zu installieren), `docker login` (um sich bei Docker mit dem Passwort anzumelden, das dem Wert der benutzerdefinierten Umgebungsvariablen entspricht, die `dockerLoginPassword` Sie im Amazon EC2 Systems Manager Parameter Store festgelegt haben) und mehrere `echo` Befehle. Die `echo` 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. In diesem Beispiel wird die einzelne Datei CodeBuild `messageUtil-1.0.jar` hochgeladen. Die Datei `messageUtil-1.0.jar` ist in dem jeweiligen Verzeichnis mit Namen `target` in der Build-Umgebung zu finden. Da `discard-paths: yes` angegeben wird, wird `messageUtil-1.0.jar` direkt hochgeladen (und nicht an ein intermediäres Verzeichnis mit dem Namen `target`). Der Dateiname `messageUtil-1.0.jar` und der dazugehörige Verzeichnisname von `target` 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 Verzeichnis `target/tests/reports`. Das Dateiformat ist `JunitXml` und der Pfad wird nicht aus den Dateien entfernt, die Testergebnisse enthalten. + `reportGroupCucumberJson` gibt eine neue Berichtsgruppe an. Wenn der Name des Projekts `my-project` lautet, wird beim Ausführen eines Builds eine Berichtsgruppe mit dem Namen `my-project-reportGroupCucumberJson` erstellt. Testergebnisse, die vom Test-Framework generiert werden, befinden sich in `cucumber/target/cucumber-tests.xml`. Das Testdateiformat ist `CucumberJson` 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 | + `environment_variables` wurde umbenannt in `env`.
+ `plaintext` wurde umbenannt in `variables`.
+ Die `type`-Eigenschaft für `artifacts` ist veraltet.
+ AWS CodeBuild Führt in Version 0.1 jeden Build-Befehl in einer separaten Instanz der Standard-Shell in der Build-Umgebung aus. In Version 0.2 werden alle Build-Befehle in derselben Instanz der Standard-Shell in der Build-Umgebung CodeBuild ausgeführt. | | 0.1 | Dies ist die erste Definition des Build-Spezifikationsformats. |