Referenz zur Build-Spezifikation für CodeBuild

Optionale Sequenz. Gibt die unterstützte Shell für Linux- oder Windows-Betriebssysteme an.

Für Linux-Betriebssysteme werden folgende Shell-Tags unterstützt:

Für Windows-Betriebssysteme werden folgende Shell-Tags unterstützt:

Erforderlich, wenn env angegeben ist und Sie benutzerdefinierte Umgebungsvariablen im Klartext definieren möchten. Enthält eine Zuordnung von key/value Skalare, wobei jede Zuordnung eine einzelne benutzerdefinierte Umgebungsvariable im Klartext darstellt. key ist der Name der benutzerdefinierten Umgebungsvariablen und value ist der Wert dieser Variablen.

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 Skalare, wobei jede Zuordnung eine einzelne benutzerdefinierte Umgebungsvariable darstellt, die im Amazon EC2 Systems Manager Parameter Store gespeichert ist. key ist der Name, den Sie später in Ihren Build-Befehlen verwenden, um auf diese benutzerdefinierte Umgebungsvariable zu verweisen, und value ist der Name der benutzerdefinierten Umgebungsvariablen, die im Amazon EC2 Systems Manager Parameter Store gespeichert ist. Informationen zum Speichern sensibler Werte finden Sie unter Systems Manager Parameter Store and Walkthrough: Create and test a String parameters (console) im Amazon EC2 Systems Manager Manager-Benutzerhandbuch.

Erforderlich, wenn Sie benutzerdefinierte Umgebungsvariablen abrufen möchten, die in gespeichert sind AWS Secrets Manager. Geben Sie einen Secrets Manager reference-key mit dem folgenden Muster an:

<key>: <secret-id>:<json-key>:<version-stage>:<version-id>

Im folgenden Beispiel TestSecret ist der Name des Schlüssel-Wert-Paares in Secrets Manager gespeichert. Der Schlüssel für TestSecret ist. MY_SECRET_VAR Sie greifen während des Builds über den 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? im AWS Secrets Manager -Benutzerhandbuch.

Optionale Zuweisung. Wird verwendet, um Umgebungsvariablen aufzulisten, die Sie exportieren möchten. Geben Sie den Namen jeder Variable, die Sie exportieren möchten, unter exported-variables in einer separaten Zeile an. Die Variable, die Sie exportieren möchten, muss während des Builds in Ihrem Container verfügbar sein. Die Variable, die Sie exportieren, kann eine Umgebungsvariable sein.

Exportierte Umgebungsvariablen werden in Verbindung mit verwendet AWS CodePipeline , um Umgebungsvariablen aus der aktuellen Buildphase in nachfolgende Phasen der Pipeline zu exportieren. Weitere Informationen finden Sie im AWS CodePipeline Benutzerhandbuch unter Arbeiten mit Variablen.

Während eines Builds ist der Wert einer Variablen ab der install-Phase verfügbar. Er kann zwischen dem Beginn 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.

Optionale Zuweisung. Wird verwendet, um anzugeben, ob sein Git-Helper für Anmeldeinformationen CodeBuild verwendet wird, um Git-Anmeldeinformationen bereitzustellen. yesob es verwendet wird. Andernfalls no oder nicht angegeben. Weitere Informationen finden Sie unter gitcredentials auf der Git-Website.

Optionale Zuweisung. Legen Sie diese auf yes fest, wenn Ihr Build in einem expliziten Proxy-Server Artefakte hochladen soll. Der Standardwert ist no.

Optionale Zuweisung. Stellen Sie auf ein, yes damit Ihr Build einen expliziten Proxyserver zur Erstellung von CloudWatch Protokollen einfügt. Der Standardwert ist no.

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: Wenn run-as global User-1 angibt und in der install-Phase eine run-as-Anweisung User-2 definiert, werden alle Befehle in der buildspec-Datei als User-1 ausgeführt, bis auf die Befehle in der install-Phase, die als User-2 ausgeführt werden.

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:

Wenn diese Eigenschaft nicht angegeben ist, folgt der Fehlerprozess den Übergangsphasen, wie unter beschriebenÜbergang von Build-Phasen.

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.

Optionale Sequenz. Stellt die Befehle dar, falls vorhanden, die während der Installation CodeBuild ausgeführt werden. Wir empfehlen Ihnen, die Phase install nur für Installationspakete in der Build-Umgebung einzusetzen. Sie könnten diese Phase beispielsweise verwenden, um ein Code-Test-Framework wie Mocha oder RSpec zu installieren.

Optionale Sequenz. Stellt die Befehle dar, falls vorhanden, die vor dem Build CodeBuild ausgeführt werden. Sie können diese Phase beispielsweise verwenden, um sich bei Amazon anzumeldenECR, oder Sie können npm-Abhängigkeiten installieren.

Optionale Sequenz. Stellt die Befehle dar, falls vorhanden, die während des Builds CodeBuild ausgeführt werden. Sie könnten diese Phase beispielsweise verwenden, um Mocha,RSpec, oder sbt auszuführen.

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 WAR OR-Datei zu packen, oder Sie könnten ein Docker-Image in Amazon pushen. ECR Dann können Sie eine Build-Benachrichtigung über Amazon sendenSNS.

Optionale Sequenz. Gibt die Berichtsgruppe an, an die die Berichte gesendet werden. Ein Projekt kann maximal fünf Berichtsgruppen haben. Geben Sie den Namen ARN einer vorhandenen Berichtsgruppe oder den Namen einer neuen Berichtsgruppe an. Wenn Sie einen Namen angeben, CodeBuild erstellt eine Berichtsgruppe mit Ihrem Projektnamen und dem Namen, den Sie im Format angeben<project-name>-<report-group-name>. Der Name der Berichtsgruppe kann auch mithilfe einer Umgebungsvariablen in der Buildspec festgelegt werden, z. B. $REPORT_GROUP_NAME Weitere Informationen finden Sie unter Benennung von Berichtsgruppen.

Erforderliche Sequenz. Stellt die Speicherorte dar, die die Rohdaten der vom Bericht generierten Testergebnisse enthalten. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem Testdateien gefunden CodeBuild werden können, und zwar relativ zum ursprünglichen Build-Speicherort oder, falls festgelegt, zum. base-directory Speicherorte können Folgendes enthalten:

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:

Optionale Zuweisung. Stellt ein oder mehrere Verzeichnisse auf oberster Ebene im Verhältnis zum ursprünglichen Build-Speicherort dar, anhand derer bestimmt wird, wo sich die CodeBuild Rohtestdateien befinden.

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.

Erforderliche Sequenz. Diese stellt die Speicherorte dar, die die Build-Ausgabeartefakte in der Build-Umgebung enthalten. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem Build-Ausgabeartefakte gefunden werden CodeBuild können, und zwar relativ zum ursprünglichen Build-Speicherort oder, falls festgelegt, zum Basisverzeichnis. Speicherorte können Folgendes enthalten:

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.

Optionaler Name. Gibt einen Namen für Ihr Build-Artefakt an. Dieser Name wird verwendet, wenn eine der folgenden Bedingungen zutrifft.

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.

Sie können dem Namen Pfadinformationen hinzufügen, sodass die benannten Artefakte auf der Grundlage des Pfads im Namen in Verzeichnissen platziert werden. In diesem Beispiel werden Build-Artefakte in der Ausgabe unter platziertbuilds/<build number>/my-artifacts.

version: 0.2
phases:
  build:
    commands:
      - rspec HelloWorld_spec.rb
artifacts:
  files:
    - '**/*'
  name: builds/$CODEBUILD_BUILD_NUMBER/my-artifacts

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 yesenthalten 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.

Optionale Zuweisung. Stellt relativ zum ursprünglichen Build-Speicherort ein oder mehrere Verzeichnisse der obersten Ebene dar, anhand derer bestimmt CodeBuild wird, welche Dateien und Unterverzeichnisse in das Build-Ausgabeartefakt aufgenommen werden sollen. Gültige Werte sind:

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

Optionale Zuweisung. Steht für einen oder mehrere Pfade, relativ zubase-directory, die Artefakte aus dem CodeBuild Build ausschließen. Das Sternchen (*) entspricht einem oder mehreren Zeichen einer Namenskomponente ohne Überschreiten der Ordnergrenzen. Ein doppeltes Sternchen (**) steht für null oder mehr Zeichen einer Namenskomponente in allen Verzeichnissen.

Beispiele für Ausschlusspfade sind die folgenden:

Optional. Wenn der Ausgabetyp istZIP, gibt er an, ob interne symbolische Links in der Datei erhalten bleiben. ZIP Wenn dieser Wert enthältyes, werden alle internen symbolischen Links in der Quelle in der ZIP Artefaktdatei beibehalten.

Optional. Gibt ein Präfix an, das verwendet wird, wenn die Artefakte in einen Amazon S3 S3-Bucket ausgegeben werden, und der Namespace-Typ istBUILD_ID. Bei Verwendung lautet <s3-prefix>/<build-id>/<name>.zip der Ausgabepfad im Bucket.

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 der artifacts-Block oben.

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

Erforderliche Sequenz. Steht für die Speicherorte des Caches. Enthält eine Folge von Skalaren, wobei jeder Skalar für einen separaten Speicherort steht, an dem Build-Ausgabeartefakte gefunden werden CodeBuild können, und zwar relativ zum ursprünglichen Build-Speicherort oder, falls festgelegt, zum Basisverzeichnis. Speicherorte können Folgendes enthalten: