Diese Seite wurde von der Cloud Translation API übersetzt.

Build-Typ: Cloud Build v1-Build

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

Build-Definition

Externe Parameter

In der folgenden Tabelle sind die Typen externer Parameter aufgeführt, die verwendet werden können in einem Cloud Build-Build. Externe Parameter sind Werte, die Sie angegeben und nicht in der Build-Konfiguration vorhanden sind. Enthält Trigger Parameter, die nicht in der cloudbuild.yaml-Datei enthalten sind.

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 (SCM-ereignisgetriggerte Builds), oder `gitFileSource` für alle anderen Triggertypen. Entweder `buildConfigSource` ODER `buildConfig` (bei Inline-Build-Konfiguration) wird festgelegt.
buildConfigSource.ref	String	Git-Referenz in `buildConfigSource.repository` von den die Konfiguration gelesen wurde, entweder als voll qualifizierte Git-Referenz (beginnt mit `refs/`) oder ein Commit-SHA (Hexadezimalwert in Kleinbuchstaben). Eine SHA-Commit-ID wird nur verwendet, wenn sie im Trigger angegeben ist.
buildConfigSource.repository	String	HTTPS-URI des Git-Repositorys, das die Build-Konfiguration enthält -Datei mit dem `https://`-Protokoll. Dieser wird vorangestellt: mit einem `git+`, um die Kompatibilität mit dem SPDX Format. Weitere Informationen zu den Formatanforderungen finden Sie unter ResourceURI enthält.
buildConfigSource.path	String	Pfad zur Build-Konfigurationsdatei im Commit. Beispiel: `cloudbuild.yaml` Schließt sich mit pathAutoDetect gegenseitig aus. Genau eines dieser Felder muss auf einen anderen Wert als den Standardwert festgelegt werden.
buildConfigSource.pathAutoDetect	boolean	Falls wahr, wurde `path` automatisch erkannt, entsprechend dem automatische Erkennung in der `BuildTrigger` ein. Wird als „Falsch“ betrachtet gleichbedeutend mit „not set“; Cloud Build verwendet stattdessen `path` wenn die automatische Erkennung nicht aktiviert ist. Schließt sich gegenseitig aus mit `path`. Genau eines dieser Felder MUSS auf einen anderen Wert als den Standardwert festgelegt sein.
sourceToBuild	Objekt	Quellcode, der ausgecheckt und erstellt wurde. In der Regel ist dies als `buildConfigSource`; unterscheiden sie sich nur, Für BuildTrigger war `gitFileSource` festgelegt. Dieses Feld ist nicht vorhanden, wenn `repository` und `ref` sind identisch mit `buildConfigSource` und `dir` ist leer. In BuildTrigger entspricht dies entweder `sourceToBuild` oder dem Commit, der den Build ausgelöst hat, je nach Triggertyp.
sourceToBuild.ref	String	Git-Referenz in `sourceToBuild.repository`, die zuvor als voll qualifizierter Git-Referenz (beginnend mit `refs/`) oder ein Commit-SHA (Hexadezimalwert in Kleinbuchstaben) haben. Eine SHA-Commit-ID wird nur verwendet, wenn sie im Trigger angegeben ist.
sourceToBuild.repository	String	HTTPS-URI des Git-Repositorys, das auscheckt wurde, mit `https://`-Protokoll. Dieser wird mit einem `git+` vorangestellt.
sourceToBuild.dir	String	Verzeichnis innerhalb des Commits, in dem der Build ausgeführt werden soll, ohne Schrägstrich. Kann leer sein.
buildConfig	String	Wenn eine Inline-Build-Konfiguration angegeben ist, z. B. bei einem manuell eingereichten Build, werden die folgenden Informationen erfasst. - Schritte - Build-Optionen (z.B. Umgebungsvariablen, Volumes, Worker) Pooldetails, Maschinentyp, Logdetails) - Substitutionen Wenn die Build-Konfiguration aus einem Repository gelesen wurde, wird sie aufgezeichnet im Abschnitt `buildConfigSource` und im Inline-Build config aus. Diese Informationen werden als base64-codierter serialisierter JSON-String gespeichert.
Substitutionen	map<string,string></string,string>	Eine Zuordnung vom Typ „String -> String“, die die Ersetzungen enthält, die an der Build-Ressource vorgenommen werden sollen. Dieser enthält nur „Laufzeit-“ oder „unabhängige“ Ersetzungen, die nicht in der Build-Konfiguration aufgezeichnet sind, d. h. über einen Trigger oder ein gcloud-CLI-Flag übergeben werden. Dieser Eintrag enthält nicht die vom System bereitgestellten Standardersetzungen, da diese werden als `internalParameters` betrachtet. Ersetzungen werden in diesem Feld angezeigt, unabhängig davon, ob sie in der Build-Konfiguration referenziert oder verwendet werden.

Interne Parameter

In der folgenden Tabelle sind die internen Parameter aufgeführt, die Cloud Build für den Build festlegt, sofern Sie sie nicht überschreiben. Weitere Informationen finden Sie unter Standardersetzungen.

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

Aufgelöste Abhängigkeiten

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

ResolvedDependencies entsprechen den ResourceDescriptor-Spezifikation.

Abhängigkeitstyp	Details
Konfigurations-Repository erstellen	Das Repository, in dem die Build-Konfiguration (d.h. das `cloudbuild.yaml`) gespeichert wurde bei ausgelösten Builds bereits abgerufen werden. Das Feld kann im Fall einer Build-Konfiguration leer sein, die nicht aus einem Repository gelesen und inline angegeben. In diesem Fall wird es weggelassen.
Quell-Repository	Das Repository, aus dem der Quellcode zum Erstellen abgerufen wurde. Sie kann mit `buildConfigSource` identisch sein oder sich davon unterscheiden. Wenn `sourceToBuild` mit `buildConfigSource` identisch ist, wird es weggelassen, z. B. bei SCM-ausgelösten Builds. `sourceToBuild` kann leer sein, wenn der Build über ausgeführt wird. `–no-source` und wird ausgelassen.

Die folgenden resolvedDependencies-Informationen enthalten beispielsweise sowohl ein buildConfigRepo als auch ein sourceRepo (die identisch sind) und ein Buildschritt-Image.

"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 ein `id`-Unterfeld, das die Build-Plattform identifiziert, die ausgeführt und die Herkunft gefüllt. Es enthält auch auf der SLSA-Ebene. Der erwartete `id`-Wert ist `https://cloudbuild.googleapis.com/GoogleHostedWorker`.
Metadaten	Zusätzliche Metadaten zu dieser bestimmten Ausführung des Builds. Unter `invocationId` wird die URL des Builds angezeigt, z. B. `https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/builds/BUILD_ID`. Die Felder `startedOn` und `finishedOn` enthalten die Zeitstempel, die angeben, wann der Build gestartet und abgeschlossen wurde.
Nebenprodukte	Wird noch nicht verwendet. Enthält zusätzliche Artefakte, die nicht als Build-Ausgabe betrachtet werden, aber für die Fehlerbehebung oder Reaktion auf Vorfälle nützlich sein können.
systemSubstitutions	Es gibt eine Teilmenge von Standardersetzungswerten, die werden automatisch in Cloud Build-Builds bereitgestellt, z. B. `PROJECT_ID`, `BUILD_ID`. Wenn Sie eine der Standardsubstitutionen von Cloud Build überschreiben, werden Ihre Substitutionen hier nicht angezeigt. Ihre Werte werden stattdessen in `externalParameters.substitutions` aufgeführt.