Build-Typ: Cloud Build v1-Build

Auf dieser Seite wird der Build-Typ für Cloud Build erläutert.

Build-Definition

Externe Parameter

Die folgende Tabelle enthält die Typen externer Parameter, die in einem Cloud Build-Build verwendet werden können. Externe Parameter sind von Ihnen festgelegte Werte, die in Ihrer Build-Konfiguration nicht vorhanden sind. Dazu gehören auch Triggerparameter, die sich nicht in der cloudbuild.yaml-Datei befinden.

Feld	Typ	Details
buildConfigSource	Objekt	Speicherort, von dem die Build-Konfiguration gelesen wurde. In `BuildTrigger` entspricht dies entweder dem Quell-Repository, das den Build ausgelöst hat (durch SCM-Ereignisse ausgelöste Builds), oder `gitFileSource` für alle anderen Triggertypen. Entweder `buildConfigSource` ODER `buildConfig` (bei einer Inline-Build-Konfiguration) wird festgelegt.
buildConfigSource.ref	String	Git-Referenz in `buildConfigSource.repository`, aus der die Konfiguration gelesen wurde, entweder als voll qualifizierte Git-Referenz (beginnend mit `refs/`) oder als Commit-SHA (Hexadezimalwert in Kleinbuchstaben). Ein Commit-SHA wird nur verwendet, wenn es im Trigger angegeben ist.
buildConfigSource.repository	String	HTTPS-URI des Git-Repositorys, das die Build-Konfigurationsdatei mit dem Protokoll `https://` enthält. Dieser wird das Präfix `git+` vorangestellt, um die Kompatibilität mit dem SPDX-Format zu gewährleisten. Weitere Informationen zu den Formatanforderungen finden Sie unter ResourceURI.
buildConfigSource.path	String	Pfad zur Build-Konfigurationsdatei innerhalb des Commits. Beispiel: `cloudbuild.yaml` Sich gegenseitig ausschließend mit pathAutodetect. Genau eines dieser Felder muss auf einen anderen Wert als den Standardwert festgelegt sein.
buildConfigSource.pathAutoDetect	boolean	Wenn „true“ festgelegt ist, wurde `path` automatisch erkannt, was der Option für die automatische Erkennung im `BuildTrigger` entspricht. „False“ wird als nicht festgelegt angesehen. Cloud Build verwendet stattdessen `path`, wenn die automatische Erkennung nicht aktiviert war. Sich gegenseitig ausschließend mit `path` Genau eines dieser Felder MUSS auf einen anderen Wert als den Standardwert gesetzt sein.
sourceToBuild	Objekt	Quellcode, der ausgecheckt und erstellt wurde. Normalerweise entspricht dies `buildConfigSource`; unterscheidet sich nur, wenn für den BuildTrigger `gitFileSource` festgelegt war. Dieses Feld ist nicht vorhanden, wenn `repository` und `ref` mit `buildConfigSource` übereinstimmen und `dir` leer ist. In BuildTrigger entspricht dies je nach Triggertyp entweder `sourceToBuild` oder dem Commit, der den Build ausgelöst hat.
sourceToBuild.ref	String	Git-Referenz in `sourceToBuild.repository`, die ausgecheckt wurde, entweder als voll qualifizierte Git-Referenz (beginnend mit `refs/`) oder als Commit-SHA (Hexadezimalwert in Kleinbuchstaben). Ein Commit-SHA wird nur verwendet, wenn es im Trigger angegeben ist.
sourceToBuild.repository	String	HTTPS-URI des Git-Repositorys, das ausgecheckt wurde, mit dem Protokoll `https://`. Dabei wird das Präfix `git+` vorangestellt.
sourceToBuild.dir	String	Verzeichnis innerhalb des Commits, in dem der Build ausgeführt werden soll, ohne abschließenden Schrägstrich. Kann leer oder nicht konfiguriert sein.
buildConfig	String	Wenn eine Inline-Build-Konfiguration bereitgestellt wird, z. B. in einem manuell gesendeten Build, werden die folgenden Informationen aufgezeichnet. – Schritte – Build-Optionen (z.B. Umgebungsvariablen, Volumes, Details zum Worker-Pool, Maschinentyp, Logdetails) – Substitutionen Wenn die Build-Konfiguration aus einem Repository gelesen wurde, wird sie im Abschnitt `buildConfigSource` aufgezeichnet und die Inline-Build-Konfiguration weggelassen. Diese Informationen werden als base64-codierter serieller JSON-String gespeichert.
Substitutionen	Map<string,string></string,string>	Zuordnung von (String -> String), die die Substitutionen enthält, die für die Build-Ressource ausgeführt werden sollen. Dies enthält nur „Laufzeit“- oder „unabhängige“ Substitutionen, die nicht in der Build-Konfiguration aufgezeichnet, also von einem Trigger oder gcloud CLI-Flag übergeben werden. In diesem Eintrag sind die vom System bereitgestellten Standardersetzungen nicht enthalten, da diese als `internalParameters` gelten. Substitutionen werden in diesem Feld unabhängig davon angezeigt, ob sie in der Build-Konfiguration referenziert oder verwendet werden.

Interne Parameter

Die folgende Tabelle enthält die internen Parameter, die Cloud Build für den Build festlegt, sofern Sie sie nicht überschreiben. Weitere Informationen finden Sie unter Standardersetzungen.

Feld	Details
triggerUri	Ressourcen-URI des Triggers, der diesen Build aufgerufen hat, in diesem Fall der vollständige Ressourcenname. Wenn der Build nicht ausgelöst wurde, wird dies weggelassen.
systemSubstitutions	Es gibt eine Teilmenge der Standardersetzungswerte, die in Cloud Build-Builds automatisch bereitgestellt werden, z. B. `PROJECT_ID` und `BUILD_ID`. Wenn Sie eine der Cloud Build-Standardersetzungen überschreiben, werden die Substitutionen hier nicht angezeigt. Ihre Werte werden stattdessen in `externalParameters.substitutions` aufgeführt.

Aufgelöste Abhängigkeiten

Wenn der Build ein Quell-Repository oder ein Build-Konfigurations-Repository hat, wird das Repository im Abschnitt resolvedDependencies der BuildDefinition beschrieben.

ResolvedDependencies entsprechen der Spezifikation ResourceDescriptor.

Abhängigkeitstyp	Details
Konfigurations-Repository erstellen	Für ausgelöste Builds das Repository, aus dem die Build-Konfiguration abgerufen wurde (d.h. das `cloudbuild.yaml`). Dies kann bei einer Build-Konfiguration leer sein, die nicht aus einem Repository gelesen wurde und inline bereitgestellt wird. In diesem Fall wird sie weggelassen.
Quell-Repository	Das Repository, aus dem der zu erstellende Quellcode abgerufen wurde. Er kann mit `buildConfigSource` identisch oder unterschiedlich sein. Ist sie identisch mit `buildConfigSource`, wird `sourceToBuild` weggelassen, beispielsweise in von SCM ausgelösten Builds. `sourceToBuild` kann leer sein, wenn der Build über `–no-source` ausgeführt wird, und wird weggelassen.

Die folgenden resolvedDependencies-Informationen enthalten beispielsweise sowohl ein BuildConfigRepo als auch sourceRepo (die identisch sind) sowie ein Image für den Build-Schritt.

"resolvedDependencies": [
{
    "uri": "git+https://github.com/octocat/hello-world.git",
    "digest": {"sha1": "7fd1a60b01f91b314f59955a4e4d4e80d8edf11d"}
}, {
    "uri": "gcr.io/cloud-builders/git",
    "digest": {
        "sha256": "28ff94e63e4058afc3f15b4c11c08cf3b54fa91faa646a4bba7158df"}
    }
]

RunDetails

Feld	Details
Builder	Enthält das Unterfeld `id`, das die Build-Plattform identifiziert, die den Vorgang ausgeführt und diese Herkunft gefüllt hat. Hier ist auch die SLSA-Ebene enthalten. Der erwartete Wert für `id` ist `https://cloudbuild.googleapis.com/GoogleHostedWorker`.
Metadaten	Zusätzliche Metadaten zu dieser speziellen Ausführung des Builds. `invocationId` zeigt die URL des Builds an, z. B. `https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/builds/BUILD_ID`. Die Felder `startedOn` und `finishedOn` enthalten die Zeitstempel für den Start und den Abschluss des Builds.
Nebenprodukte	Wird noch nicht verwendet. Enthält zusätzliche Artefakte, die nicht als Ausgabe des Builds betrachtet werden, aber für die Fehlerbehebung oder Reaktion auf Vorfälle nützlich sein können.
systemSubstitutions	Es gibt eine Teilmenge der Standardersetzungswerte, die in Cloud Build-Builds automatisch bereitgestellt werden, z. B. `PROJECT_ID` und `BUILD_ID`. Wenn Sie eine der Cloud Build-Standardersetzungen überschreiben, werden die Substitutionen hier nicht angezeigt. Ihre Werte werden stattdessen in `externalParameters.substitutions` aufgeführt.