Questa pagina è stata tradotta dall'API Cloud Translation.

Schema del file di configurazione di compilazione

Un file di configurazione di compilazione contiene le istruzioni per l'esecuzione di Cloud Build attività in base alle tue specifiche. Ad esempio, il file di configurazione della build contengono istruzioni per creare, pacchettizzare ed eseguire il push delle immagini Docker.

Questa pagina illustra lo schema del file di configurazione di Cloud Build. Per istruzioni su come creare e utilizzare un file di configurazione della build, consulta la sezione Creare un file di configurazione della build di base.

Struttura di un file di configurazione di compilazione

I file di configurazione della build vengono modellati utilizzando la risorsa Build dell'API Cloud Build.

Puoi scrivere il file di configurazione della build utilizzando la sintassi YAML o JSON. Se inviare richieste di build utilizzando strumenti HTTP di terze parti come curl, utilizzare a riga di comando.

Un file di configurazione della build ha la seguente struttura:

YAML

steps:
- name: string
  args: [string, string, ...]
  env: [string, string, ...]
  allowFailure: boolean
  allowExitCodes: [string (int64 format), string (int64 format), ...]
  dir: string
  id: string
  waitFor: [string, string, ...]
  entrypoint: string
  secretEnv: string
  volumes: object(Volume)
  timeout: string (Duration format)
  script: string
  automapSubstitutions: boolean
- name: string
  ...
- name: string
  ...
timeout: string (Duration format)
queueTtl: string (Duration format)
logsBucket: string
options:
 env: [string, string, ...]
 secretEnv: string
 volumes: object(Volume)
 sourceProvenanceHash: enum(HashType)
 machineType: enum(MachineType)
 diskSizeGb: string (int64 format)
 substitutionOption: enum(SubstitutionOption)
 dynamicSubstitutions: boolean
 automapSubstitutions: boolean
 logStreamingOption: enum(LogStreamingOption)
 logging: enum(LoggingMode)
 defaultLogsBucketBehavior: enum(DefaultLogsBucketBehavior)
 pool: object(PoolOption)
 requestedVerifyOption: enum(RequestedVerifyOption)
substitutions: map (key: string, value: string)
tags: [string, string, ...]
serviceAccount: string
secrets: object(Secret)
availableSecrets: object(Secrets)
artifacts: object(Artifacts)
  mavenArtifacts: [object(MavenArtifact), ...]
  pythonPackages: [object(PythonPackage), ...]
  npmPackages: [object(npmPackage), ...]
images:
- [string, string, ...]

JSON

{
    "steps": [
    {
        "name": "string",
        "args": [
            "string",
            "string",
            "..."
        ],
        "env": [
            "string",
            "string",
            "..."
        ],
        "allowFailure": "boolean",
        "allowExitCodes: [
            "string (int64 format)",
            "string (int64 format)",
            "..."
        ],
        "dir": "string",
        "id": "string",
        "waitFor": [
            "string",
            "string",
            "..."
        ],
        "entrypoint": "string",
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "timeout": "string (Duration format)",
        "script" : "string",
        "automapSubstitutions" : "boolean"
    },
    {
        "name": "string"
        ...
    },
    {
        "name": "string"
        ...
    }
    ],
    "timeout": "string (Duration format)",
    "queueTtl": "string (Duration format)",
    "logsBucket": "string",
    "options": {
        "sourceProvenanceHash": "enum(HashType)",
        "machineType": "enum(MachineType)",
        "diskSizeGb": "string (int64 format)",
        "substitutionOption": "enum(SubstitutionOption)",
        "dynamicSubstitutions": "boolean",
        "automapSubstitutions": "boolean",
        "logStreamingOption": "enum(LogStreamingOption)",
        "logging": "enum(LoggingMode)"
        "defaultLogsBucketBehavior": "enum(DefaultLogsBucketBehavior)"
        "env": [
            "string",
            "string",
            "..."
        ],
        "secretEnv": "string",
        "volumes": "object(Volume)",
        "pool": "object(PoolOption)"
        "requestedVerifyOption": "enum(RequestedVerifyOption)"
    },
    "substitutions": "map (key: string, value: string)",
    "tags": [
        "string",
        "string",
        "..."
    ],
    "serviceAccount": "string",
    "secrets": "object(Secret)",
    "availableSecrets": "object(Secrets)",
    "artifacts": "object(Artifacts)",
      "mavenArtifacts": ["object(MavenArtifact)", ...],
      "pythonPackages": ["object(PythonPackage)", ...],
      "npmPackages": ["object(npmPackage)", ...],
    "images": [
        "string",
        "string",
        "..."
    ]
}

Ognuna delle sezioni del file di configurazione di compilazione definisce una parte dell'attività vuoi che Cloud Build esegua:

Passi build

Un passaggio di build specifica un'azione che deve essere eseguita da Cloud Build eseguire il deployment. Per ogni passaggio di build, Cloud Build esegue un container Docker come un'istanza di docker run. I passaggi di compilazione sono analoghi ai comandi in uno script e ti offrono la flessibilità di eseguire istruzioni arbitrarie nella compilazione. Se puoi pacchettizzare uno strumento di compilazione in un contenitore, Cloud Build può eseguirlo nell'ambito della compilazione. Per impostazione predefinita, Cloud Build esegue tutti i passaggi di una build in sequenza sulla stessa macchina. Se hai passaggi che possono essere eseguiti contemporaneamente, utilizza l'opzione waitFor.

Puoi includere fino a 300 passaggi di compilazione nel file di configurazione.

Utilizza il campo steps nel file di configurazione della build per specificare un passaggio di compilazione. Ecco un frammento del tipo di configurazione che potresti impostare nel campo steps:

YAML

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/mydepl', 'my-image=gcr.io/my-project/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image"
            "deployment/mydepl"
            "my-image=gcr.io/my-project/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
            "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`name`

Utilizza il campo name di un passaggio di compilazione per specificare un cloud builder, ovvero un'immagine container che esegue strumenti comuni. Utilizzi un generatore in un passaggio di compilazione per eseguire le attività.

Lo snippet seguente mostra i passaggi di build che chiamano il bazel, gcloud e Gli builder di docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/bazel'
...

- name: 'gcr.io/cloud-builders/gcloud'
...

- name: 'gcr.io/cloud-builders/docker'
...

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/bazel"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/gcloud"
        ...
    },
    {
        "name": "gcr.io/cloud-builders/docker"
        ...
    }
    ]
}

`args`

Il campo args di un passaggio di build accetta un elenco di argomenti e li passa a al builder a cui fa riferimento il campo name. Gli argomenti passati al builder sono passate allo strumento in esecuzione nello strumento di creazione, il che ti consente di richiamare qualsiasi supportato dallo strumento. Se il builder utilizzato nel passaggio di build ha un valore gli argomenti verranno utilizzati come argomenti per quel punto di ingresso. Se lo strumento non definisce un punto di ingresso, il primo elemento negli argomenti verrà utilizzato come il punto di ingresso, mentre il resto verrà utilizzato come argomenti.

Puoi creare fino a 100 argomenti per passaggio. La lunghezza massima dell'argomento è di 10.000 caratteri.

Il seguente snippet richiama il comando docker build e installa le dipendenze Maven:

YAML

steps:
- name: 'gcr.io/cloud-builders/mvn'
  args: ['install']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project-id/myimage', '.']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/mvn",
        "args": [
            "install"
        ]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/my-project-id/myimage",
            "."
        ]
    }
    ]
}

`env`

Il campo env di un passaggio di build richiede un elenco di variabili di ambiente da utilizzare durante l'esecuzione del passaggio. Il formato delle variabili è KEY=VALUE.

Nella seguente configurazione di compilazione, il campo env del passaggio di compilazione imposta la zona Compute Engine e il cluster GKE prima dell'esecuzionekubectl:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['set', 'image', 'deployment/myimage', 'frontend=gcr.io/myproject/myimage']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=us-east1-b'
  - 'CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    {
        "name": "gcr.io/cloud-builders/kubectl",
        "args": [
            "set",
            "image",
            "deployment/myimage",
            "frontend=gcr.io/myproject/myimage"
        ],
        "env": [
            "CLOUDSDK_COMPUTE_ZONE=us-east1-b",
            "CLOUDSDK_CONTAINER_CLUSTER=node-example-cluster"
        ]
    }
    ]
}

`dir`

Utilizza il campo dir in un passaggio di build per impostare una directory di lavoro da usare quando che esegue il container del passaggio. Se imposti il campo dir nel passaggio di build, la directory di lavoro è impostata su /workspace/<dir>. Se questo valore è un valore relativo percorso, è relativo alla directory di lavoro della build. Se questo valore è assoluto, potrebbe trovarsi al di fuori della directory di lavoro del build, nel qual caso i contenuti del percorso potrebbero non essere mantenuti nelle esecuzioni dei passaggi di compilazione (a meno che non sia specificato un volume per il percorso).

Lo snippet di codice riportato di seguito imposta la directory di lavoro per il passaggio di build come /workspace/examples/hello_world:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
  env: ['PROJECT_ROOT=hello']
  dir: 'examples/hello_world'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ],
        "env": [
            "PROJECT_ROOT=hello"
        ],
        "dir": "examples/hello_world"
    }
    ]
}

`timeout`

Utilizza il campo timeout in un passaggio di build per impostare un limite di tempo per l'esecuzione passaggio. Se non imposti questo campo, il passaggio non ha limiti di tempo e potrà essere eseguito fino al completamento o al timeout della compilazione stessa. Il campo timeout in un passaggio di build non deve superare timeout specificato per una build. timeout deve essere specificato in secondi con un massimo di nove cifre frazionarie, che termina con "s". Esempio: 3.5s

Nella configurazione di compilazione seguente, il passaggio ubuntu scade dopo 500 secondi:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
  timeout: 500s
- name: 'ubuntu'
  args: ['echo', 'hello world, after 600s']

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ],
        "timeout": "500s"
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello world, after 600s"
        ]
    }
    ]
}

copione

Utilizza il campo script in un passaggio di build per specificare uno script shell da eseguire in per completare il passaggio. Se specifichi script in un passaggio di build, non puoi specificare args o entrypoint nello stesso passaggio. Per istruzioni sull'utilizzo del campo script, consulta Eseguire script bash.

automapSubstitutions

Se impostato su true, mappa automaticamente tutte le sostituzioni e le rende disponibili come variabili di ambiente in un unico passaggio. Se impostato su false, ignora le sostituzioni per quel passaggio. Per alcuni esempi, consulta Valori delle variabili sostitutivi.

ID

Utilizza il campo id per impostare un identificatore univoco per un passaggio di build. id viene utilizzato con il campo waitFor per configurare l'ordine in cui devono essere eseguiti i passaggi di compilazione. Per istruzioni sull'utilizzo di waitFor e id, consulta Configurare l'ordine dei passaggi di compilazione.

`waitFor`

Utilizza il campo waitFor in un passaggio di compilazione per specificare i passaggi da eseguire prima del passaggio di compilazione. Se non vengono forniti valori per waitFor, il passaggio di build attende il completamento di tutti i passaggi di build precedenti nella richiesta di build prima dell'esecuzione. Per istruzioni sull'utilizzo di waitFor e id, consulta Configurazione passaggio di build ordine.

`entrypoint`

Usa entrypoint in un passaggio di build per specificare un punto di ingresso se non vuoi per utilizzare il punto di ingresso predefinito del builder. Se non imposti questo campo, Cloud Build utilizzerà il punto di ingresso del builder. Il seguente snippet imposta i punti di ingresso per il passaggio di build npm:

YAML

steps:
- name: 'gcr.io/cloud-builders/npm'
  entrypoint: 'node'
  args: ['--version']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/npm",
        "entrypoint": "node",
        "args": [
            "--version"
        ]
    }
    ]
}

`secretEnv`

Un elenco di variabili di ambiente criptate con Cloud KMS di crittografia. Questi valori devono essere specificati nei secret della build. Per informazioni sull'utilizzo di questo campo, consulta Utilizzare la variabile criptata nelle richieste di compilazione.

`volumes`

Un volume è un volume del container Docker montato nei passaggi di build per mantenere i file tra i passaggi di build. Quando Cloud Build esegue un passaggio di build, monta un volume workspace in /workspace. Puoi specificare volumi aggiuntivi da montare nei container dei passaggi di compilazione utilizzando il campo volumes per i passaggi.

Ad esempio, il seguente file di configurazione della build scrive un file in un volume nel primo passaggio e lo legge nel secondo. Se in questi passaggi non è stato specificato /persistent_volume come volume permanente, il primo passaggio scriverà file in quel percorso, il file verrà eliminato prima del secondo passaggio . Se specifichi il volume con lo stesso nome in entrambi i passaggi, i contenuti di /persistent_volume nel primo passaggio vengono mantenuti nel secondo.

YAML

steps:
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
        echo "Hello, world!" > /persistent_volume/file
- name: 'ubuntu'
  volumes:
  - name: 'vol1'
    path: '/persistent_volume'
  args: ['cat', '/persistent_volume/file']

JSON

  {
    "steps": [
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "entrypoint": "bash",
        "args": [
          "-c",
          "echo \"Hello, world!\" > /persistent_volume/file\n"
        ]
      },
      {
        "name": "ubuntu",
        "volumes": [
          {
            "name": "vol1",
            "path": "/persistent_volume"
          }
        ],
        "args": [
          "cat",
          "/persistent_volume/file"
        ]
     }
    ]
  }

`allowFailure`

In un passaggio di build, se imposti il valore del campo allowFailure su true e il passaggio di build non riesce, la build riesce a condizione che tutti gli altri passaggi di quella build vadano a buon fine.

Se tutti i passaggi di build in una build hanno allowFailure impostato su true e tutti i passaggi di build hanno esito negativo, lo stato della build è ancora Successful.

allowExitCodes ha la precedenza su questo campo.

Il seguente snippet di codice consente il completamento della compilazione quando il primo passaggio non va a buon fine:

YAML

steps:
- name: 'ubuntu'
  args: ['-c', 'exit 1']
  allowFailure: true
steps:
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit -1"
        ],
        "allowFailure": true,
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`allowExitCodes`

Utilizza il campo allowExitCodes per specificare che un errore di un passaggio di compilazione può essere ignorato quando il passaggio restituisce un determinato codice di uscita.

Se un passaggio di build ha esito negativo con un codice di uscita corrispondente al valore che hai fornito in allowExitCodes, Cloud Build consentirà l'esito negativo di questo passaggio di build senza danneggiare l'intera build.

Se il 100% dei passaggi di build non riesce, ma ogni passaggio viene chiuso con un codice che hai specificato nel campo allowExitCodes, la build viene comunque completata.

Tuttavia, se il passaggio di compilazione non va a buon fine e genera un altro codice di uscita, che non corrisponde al valore specificato in allowExitCodes, la compilazione complessiva non andrà a buon fine.

I codici di uscita pertinenti alla compilazione dipendono dal software. Ad esempio, "1" è un codice di uscita comune in Linux. Puoi anche definire i tuoi codici di uscita negli script. Il campo allowExitCodes accetta numeri fino a un massimo di 255.

Questo campo ha la precedenza su allowFailure.

Il seguente snippet di codice consente alla build di riuscire quando il primo passaggio non riesce con uno dei codici di uscita forniti:

YAML

steps:
- name: 'ubuntu'
  args: ['-c', 'exit 1']
  allowExitCodes: [1]
steps:
- name: 'ubuntu'
  args: ['echo', 'Hello World']

JSON

{
  "steps": [
    {
        "name": "ubuntu",
        "args": [
            "-c",
            "exit 1"
        ],
        "allowExitCodes": [1],
    },
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "Hello World"
        ]
    }
  ]
}

`timeout`

Utilizza il campo timeout per una build per specificare per quanto tempo l'esecuzione deve essere consentita con una granularità al secondo. Se questo periodo di tempo scade, il lavoro sulla compilazione verrà interrotto e lo stato della compilazione sarà TIMEOUT. Se timeout non è impostato, alla compilazione verrà applicato un valore predefinito di 60 minuti per timeout. Il valore massimo che può essere applicato a timeout è 24 ore. timeout deve essere specificato in secondi con un massimo di nove cifre frazionarie, che termina con "s". Esempio: 3.5s

Nel seguente snippet, il valore timeout è impostato su 660 secondi per evitare la build di timeout a causa del sonno:

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '600']
timeout: 660s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "600"
        ]
    }
    ],
    "timeout": "660s"
}

`queueTtl`

Utilizza il campo queueTtl per specificare il periodo di tempo per cui una build può essere messa in coda. Se una compilazione è in coda per più tempo del valore impostato in queueTtl, scade e lo stato della compilazione viene impostato su EXPIRED. Se non viene fornito alcun valore, Cloud Build utilizza il valore predefinito 3600s (1 ora). queueTtl inizia a titolare da createTime. queueTtl deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminanti con "s", ad esempio 3.5s.

Nel seguente snippet, timeout è impostato su 20s e queueTtl è impostato su 10s. Il numero di queueTtl inizia alle ore createTime, ovvero il momento in cui viene creata e timeout inizia a ticchettare alle ore startTime, che è l'ora in cui viene avviata la build. Pertanto, queueTtl scadrà alle ore createTime + 10s, a meno che la compilazione non venga avviata entro questa data.

YAML

steps:
- name: 'ubuntu'
  args: ['sleep', '5']
timeout: 20s
queueTtl: 10s

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "sleep",
            "5"
        ]
    }
    ],
    "timeout": "20s",
    "queueTtl": "10s"
}

`logsBucket`

Imposta il campo logsBucket per una build per specificare un bucket Cloud Storage in cui devono essere scritti i log. Se non imposti questo campo, Cloud Build utilizzerà un bucket predefinito per archiviare i log di compilazione.

Lo snippet seguente imposta un bucket di log in cui archiviare i log di build:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
logsBucket: 'gs://mybucket'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "logsBucket": "gs://mybucket"
}

`options`

Utilizza il campo options per specificare i seguenti argomenti facoltativi per la compilazione:

env: Un elenco di definizioni di variabile di ambiente globali che esisteranno per tutte le build passaggi in questa build. Se una variabile è definita sia a livello globale sia in un passaggio di compilazione, utilizzerà il valore del passaggio di compilazione. Gli elementi hanno questo formato A KEY=VALUE per la variabile di ambiente KEY viene assegnato il valore VALUE.

secretEnv: un elenco di variabili di ambiente globali, criptate utilizzando una chiave di crittografia Cloud Key Management Service, che sarà disponibile per tutti i passaggi di compilazione in questa compilazione. Questi valori devono essere specificati nel valore Secret della build.

volumes: Un elenco di volumi da montare a livello globale per TUTTI i passaggi di build. Ogni volume viene creato come volume vuoto prima di iniziare il processo di compilazione. Al termine della compilazione, i volumi e i relativi contenuti vengono eliminati. I nomi e i percorsi dei volumi globali non possono entrare in conflitto con i volumi definiti in un passaggio di compilazione. L'utilizzo di un volume globale in una compilazione con un solo passaggio non è valido in quanto indica una richiesta di compilazione con una configurazione errata.

sourceProvenanceHash: Imposta l'opzione sourceProvenanceHash per specificare l'algoritmo hash per l'origine provenienza. Lo snippet riportato di seguito specifica che l'algoritmo hash è SHA256:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    sourceProvenanceHash: ['SHA256']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "sourceProvenanceHash": ["SHA256"]
    }
}

machineType: Cloud Build fornisce quattro tipi di macchine virtuali con CPU elevata per eseguire le build: due tipi di macchine con 8 CPU e due tipi di macchine con 32 CPU. Cloud Build offre inoltre altri due tipi di macchine virtuali con 1 e 2 CPU per eseguire le build. Il tipo di macchina predefinito è e2-standard-2 con 2 CPU. La richiesta di una macchina virtuale con più CPU può aumentare il tempo di avvio della tua build. Aggiungi l'opzione machineType per richiedere una macchina virtuale con una CPU più alta:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 machineType: 'E2_HIGHCPU_8'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    },
    ],
    "options": {
        "machineType": "E2_HIGHCPU_8"
    }
}

Per ulteriori informazioni sull'utilizzo dell'opzione machineType, consulta Velocizzare le compilazioni.

diskSizeGb: utilizza l'opzione diskSizeGb per richiedere una dimensione del disco personalizzata per la tua build. La la dimensione massima che puoi richiedere è 4000 GB.

Lo snippet seguente richiede una dimensione del disco di 200 GB:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 diskSizeGb: '200'

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "diskSizeGb": '200'
    }
}

logStreamingOption: Utilizza questa opzione per specificare se vuoi eseguire il flusso dei log di build di archiviazione ideale in Cloud Storage. Per impostazione predefinita, Cloud Build raccoglie i log di compilazione al termine della compilazione. Questa opzione specifica se vuoi eseguire lo streaming dei log di compilazione in tempo reale durante il processo di compilazione. Lo snippet seguente specifica che i log di build vengono trasmesse in flussi a Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['install', '.']
options:
 logStreamingOption: STREAM_ON

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "install",
            "."
        ]
    }
    ],
    "options": {
        "logStreamingOption": "STREAM_ON"
    }
}

logging: Utilizza questa opzione per specificare se vuoi archiviare i log in Cloud Logging o Cloud Storage. Se non imposti questa opzione, Cloud Build archivia i log sia in Cloud Logging sia in Cloud Storage. Puoi imposta l'opzione logging su GCS_ONLY per archiviare i log solo in di archiviazione ideale in Cloud Storage. Lo snippet seguente specifica che i log vengono archiviati in Cloud Storage:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
 logging: GCS_ONLY

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "logging": "GCS_ONLY"
    }
}

defaultLogsBucketBehavior: l'opzione defaultLogsBucketBehavior ti consente di configurare Cloud Build per creare un bucket dei log predefinito all'interno del tuo progetto nella stessa regione della build. Per ulteriori informazioni, vedi Archiviare i log di compilazione in un bucket di proprietà dell'utente e regionalizzato.

La seguente configurazione di compilazione imposta il campo defaultLogsBucketBehavior sul valore REGIONAL_USER_OWNED_BUCKET:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ]
options:
  defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "-t",
        "us-central1-docker.pkg.dev/myproject/myrepo/myimage",
        "."
      ]
    }
    ],
    "options": {
      "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET"
    }
}

dynamicSubstitutions: utilizza questa opzione per attivare o disattivare esplicitamente l'espansione dei parametri bash nelle sostituzioni. Se la compilazione viene invocata da un trigger, il campo dynamicSubstitutions viene sempre impostato su true e non deve essere specificato nel file di configurazione della compilazione. Se la compilazione viene invocata manualmente, devi impostare il campo dynamicSubstitutions su true affinché le espansioni dei parametri bash vengano interpretate durante l'esecuzione della compilazione.

automapSubstitutions: mappa automaticamente tutte le sostituzioni alle variabili di ambiente che saranno disponibili durante l'intera build. Per alcuni esempi, vedi Sostituisci i valori delle variabili.

substitutionOption: Imposterai questa opzione insieme al campo substitutions di seguito per specificare il comportamento quando si verifica un errore di sostituzione controlli.

pool: imposta il valore di questo campo sul nome della risorsa del pool privato in cui eseguire la compilazione. Per istruzioni su come eseguire una build in un pool privato, consulta Eseguire le build in un pool privato.

requestedVerifyOption: Imposta il valore requestedVerifyOption su VERIFIED per attivare e verificare generazione di attestati e metadati di provenienza per la tua build. Una volta impostato, le build verranno contrassegnate come SUCCESS solo se vengono generate attestazioni e provenienza.

`substitutions`

Utilizza le sostituzioni nel file di configurazione della build per sostituire variabili specifiche in in fase di creazione. Le sostituzioni sono utili per le variabili il cui valore non è noto fino alla fase di compilazione o per riutilizzare una richiesta di build esistente con variabili diverse e i relativi valori. Per impostazione predefinita, la compilazione restituisce un errore se manca una variabile di sostituzione o una sostituzione. Tuttavia, puoi utilizzare l'opzione ALLOW_LOOSE. per saltare questo controllo.

Lo snippet seguente utilizza le sostituzioni per stampare "Hello World". L'opzione di sostituzione ALLOW_LOOSE è impostata, il che significa che la compilazione non restituirà un errore se manca una variabile di sostituzione o una sostituzione.

YAML

steps:
- name: 'ubuntu'
  args: ['echo', 'hello ${_SUB_VALUE}']
substitutions:
    _SUB_VALUE: world
options:
    substitution_option: 'ALLOW_LOOSE'

JSON

{
    "steps": [
    {
        "name": "ubuntu",
        "args": [
            "echo",
            "hello ${_SUB_VALUE}"
        ]
    }
    ],
    "substitutions": {
        "_SUB_VALUE": "world"
},
    "options": {
        "substitution_option": "ALLOW_LOOSE"
    }
}

Per ulteriori istruzioni sull'utilizzo di substitutions, consulta Sostituisci valori variabili.

`tags`

Utilizza il campo tags per organizzare le build in gruppi e filtrare le build. La seguente configurazione imposta due tag denominati mytag1 e mytag2:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  ...
- name: 'ubuntu'
  ...
tags: ['mytag1', 'mytag2']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker"
    },
    {
        "name": "ubuntu"
    }
    ],
    "tags": [
        "mytag1",
        "mytag2"
    ]
}

`availableSecrets`

Utilizza questo campo per utilizzare un secret di Secret Manager con Cloud Build. Per ulteriori informazioni, consulta la sezione Utilizzare i secret.

`secrets`

Il secret abbina un insieme di variabili di ambiente secret contenenti con la chiave Cloud KMS da utilizzare per decriptare il valore.

`serviceAccount`

Utilizza questo campo per specificare l'account di servizio IAM da utilizzare al momento della compilazione. Per ulteriori informazioni, consulta la pagina sulla configurazione degli account di servizio specificati dall'utente.

`images`

Il campo images nel file di configurazione di compilazione specifica una o più immagini Docker Linux da spingere da Cloud Build ad Artifact Registry o Container Registry (Ritirato). Potresti avere una build che esegue attività senza producendo immagini Docker Linux, ma se crei immagini e non ne esegui il push al registro, le immagini vengono ignorate al completamento della build. Se un'immagine specificata non viene prodotta durante la compilazione, la compilazione non andrà a buon fine. Per maggiori informazioni informazioni sull'archiviazione delle immagini, vedi Archivia gli artefatti in Artifact Registry.

La seguente configurazione di compilazione imposta il campo images per archiviare l'immagine creata:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
images: ['gcr.io/myproject/myimage']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "images": [
        "gcr.io/myproject/myimage"
    ]
}

`artifacts`

Il campo artifacts nel file di configurazione della compilazione specifica uno o più gli artefatti non contenitore da archiviare in Cloud Storage. Per ulteriori informazioni per l'archiviazione di artefatti non containerizzati, consulta Archiviare gli artefatti di build in Cloud Storage.

La seguente configurazione di compilazione imposta il campo artifacts per archiviare il pacchetto Go compilato in gs://mybucket/:

YAML

steps:
- name: 'gcr.io/cloud-builders/go'
  args: ['build', 'my-package']
artifacts:
  objects:
    location: 'gs://mybucket/'
    paths: ['my-package']

JSON

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/go",
        "args": [
            "build",
            "my-package"
        ]
    }
    ],
    "artifacts": {
      "objects": {
        "location": "gs://mybucket/",
        "paths": [
            "my-package"
        ]
      }
    }
}

`mavenArtifacts`

Il campo mavenArtifacts ti consente di caricare artefatti Java non containerizzati nei repository Maven in Artifact Registry. Per ulteriori informazioni, vedi Creare e testare applicazioni Java.

La seguente configurazione di compilazione imposta il campo mavenArtifacts per caricare il file pacchettizzato my-app-1.0-SNAPSHOT.jar nel repository Artifact Registry https://us-central1-maven.pkg.dev/my-project-id/my-java-repo:

YAML

artifacts:
  mavenArtifacts:
    - repository: 'https://us-central1-maven.pkg.dev/my-project-id/my-java-repo'
      path: '/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar'
      artifactId: 'my-app-1'
      groupId: 'com.mycompany.app'
      version: '1.0.0'

JSON

{
  "artifacts": {
    "mavenArtifacts": [
      {
        "repository": "https://us-central1-maven.pkg.dev/my-project-id/my-java-repo",
        "path": "/workspace/my-app/target/my-app-1.0-SNAPSHOT.jar",
        "artifactId": "my-app-1",
        "groupId": "com.mycompany.app",
        "version": "1.0.0"
      }
    ]
  }
}

`pythonPackages`

Il campo pythonPackages ti consente di caricare i pacchetti Python in Artifact Registry. Per ulteriori informazioni, consulta Creare e testare applicazioni Python.

La seguente configurazione di compilazione imposta il campo pythonPackages per caricare il pacchetto Python dist/my-pkg.whl nel repository Artifact Registry https://us-east1-python.pkg.dev/my-project/my-repo:

YAML

artifacts:
  pythonPackages:
   - repository: 'https://us-east1-python.pkg.dev/my-project/my-repo'
     paths: ['dist/my-pkg.whl']

JSON

{
  "artifacts": {
    "pythonPackages": [
      {
        "repository": "https://us-east1-python.pkg.dev/my-project/my-repo",
        "paths": ["dist/my-pkg.whl"]
      }
    ]
  }
}

`npmPackages`

Utilizza il campo npmPackages per configurare Cloud Build in modo da caricare ha creato pacchetti npm nei repository supportati in Artifact Registry. Devi fornisce i valori per repository e packagePath.

Il campo repository specifica il repository Artifact Registry in cui archiviare le tue pacchetti. Il campo packagePath specifica la directory locale che contiene il pacchetto npm da caricare. Questa directory deve contenere un file package.json.

Ti consigliamo di utilizzare un percorso assoluto per il valore packagePath. Puoi utilizzare la modalità . per fare riferimento alla directory di lavoro attuale, ma il campo non può essere omesso o lasciato vuoto. Per ulteriori istruzioni sull'utilizzo di npmPackages, consulta Creare e testare applicazioni Node.js.

La seguente configurazione di build imposta il campo npmPackages per caricare il file npm pacchetto nella directory /workspace/my-pkg al repository Artifact Registry https://us-east1-npm.pkg.dev/my-project/my-repo.

YAML

artifacts:
  npmPackages:
   - repository: 'https://us-east1-npm.pkg.dev/my-project/my-repo'
     packagePath: '/workspace/my-pkg'

JSON

{
  "artifacts": {
    "npmPackages": [
      {
        "repository": "https://us-east1-npm.pkg.dev/my-project/my-repo",
        "packagePath": "/workspace/my-pkg"
      }
    ]
  }
}

Utilizzo dei Dockerfile

Se esegui build Docker in Cloud Build utilizzando l'interfaccia a riga di comando gcloud o gli trigger di compilazione, puoi utilizzare un Dockerfile senza un file di configurazione di compilazione separato. Se vuoi apportare ulteriori modifiche alle build Docker, puoi fornire un file di configurazione di compilazione oltre a Dockerfile. Per istruzioni su come creare un'immagine Docker utilizzando un Dockerfile, consulta la Guida rapida: compilazione.

Rete Cloud Build

Quando Cloud Build esegue ogni passaggio di compilazione, collega il relativo container a una rete Docker locale denominata cloudbuild. La rete cloudbuild ospita le credenziali predefinite dell'applicazione (ADC) che i servizi Google Cloud possono utilizzare per trovare automaticamente le tue credenziali. Se esegui container Docker nidificati e vuoi esporre ADC a un container sottostante o utilizzare gcloud in un passaggio docker, usa il flag --network nel passaggio build della finestra Docker:

YAML

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '--network=cloudbuild', '.']

JSON

{
  "steps": [
    {
      "name": "gcr.io/cloud-builders/docker",
      "args": [
        "build",
        "--network=cloudbuild",
        "."
      ]
   }
  ]
}

Passaggi successivi

Scopri come creare un file di configurazione della build di base per configurare le build per Cloud Build.
Leggi Avvio di una build Manualmente per istruzioni su come eseguire le build in Cloud Build.