Schema del file di configurazione di compilazione

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

Questa pagina spiega lo schema del file di configurazione di Cloud Build. Per istruzioni sulla creazione e sull'utilizzo di un file di configurazione della build, vedi Creazione di un file di configurazione della build di base.

Struttura di un file di configurazione della build

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

Puoi scrivere il file della configurazione di compilazione utilizzando la sintassi YAML o JSON. Se invii richieste di build utilizzando strumenti http di terze parti come curl, usa la sintassi JSON.

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)
 pubsubTopic: string
 requestedVerifyOption: enum(RequestedVerifyOption)
substitutions: map (key: string, value: string)
tags: [string, string, ...]
serviceAccount: string
secrets: object(Secret)
availableSecrets: object(Secrets)
artifacts: object(Artifacts)
  goModules: [object(GoModules), ...]
  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)",
      "goModules": [object(GoModules), ...],
      "mavenArtifacts": ["object(MavenArtifact)", ...],
      "pythonPackages": ["object(PythonPackage)", ...],
      "npmPackages": ["object(npmPackage)", ...],
    "images": [
        "string",
        "string",
        "..."
    ]
}

Ogni sezione del file di configurazione di compilazione definisce una parte dell'attività che vuoi che Cloud Build esegua:

Passi build

Un passaggio di build specifica un'azione che vuoi che Cloud Build esegua. Per ogni passaggio di build, Cloud Build esegue un container Docker come istanza di docker run. I passaggi di build sono analoghi ai comandi di uno script e ti offrono la flessibilità di eseguire istruzioni arbitrarie nella build. Se puoi pacchettizzare uno strumento di compilazione in un container, 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 build nel file di configurazione.

Utilizza il campo steps nel file di configurazione della build per specificare un passaggio della build. Ecco un snippet 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 build per specificare un cloud builder, ovvero un'immagine container che esegue strumenti comuni. Utilizzi un builder in un passaggio di build per eseguire le tue attività.

Lo snippet seguente mostra i passaggi di build che chiamano i builder bazel, gcloud e 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 al builder a cui fa riferimento il campo name. Gli argomenti passati al builder vengono passati allo strumento in esecuzione nel builder, il che ti consente di richiamare qualsiasi comando supportato dallo strumento. Se il builder utilizzato nel passaggio di build ha un punto di ingresso, gli argomenti verranno utilizzati come argomenti per quel punto di ingresso. Se il builder non definisce un punto di ingresso, il primo elemento in args verrà utilizzato come punto di ingresso e 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 accetta un elenco di variabili di ambiente da utilizzare durante l'esecuzione del passaggio. Le variabili sono nel formato KEY=VALUE.

Nella seguente configurazione della build, il campo env del passaggio di build imposta la zona Compute Engine e il cluster GKE prima dell'esecuzione di kubectl:

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 utilizzare durante l'esecuzione del container del passaggio. Se imposti il campo dir nel passaggio di build, la directory di lavoro è impostata su /workspace/<dir>. Se questo valore è un percorso relativo, è relativo alla directory di lavoro della build. Se questo valore è assoluto, potrebbe trovarsi al di fuori della directory di lavoro della build, nel qual caso i contenuti del percorso potrebbero non essere mantenuti durante le esecuzioni dei passaggi di build (a meno che non venga specificato un volume per quel percorso).

Il seguente snippet di codice 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 del passaggio. Se non imposti questo campo, il passaggio viene eseguito fino al completamento o fino al timeout della build stessa. Il campo timeout per un passaggio di build non deve superare il valore timeout specificato per la build.

timeout è specificato in secondi (utilizzando il formato Durata) con un massimo di nove cifre frazionarie, che termina con s (ad esempio: 3.5s).

Nella seguente configurazione di build, 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"
        ]
    }
    ]
}

script

Utilizza il campo script in un passaggio di build per specificare uno script shell da eseguire nel 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 Esecuzione di 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 esempi, vedi Sostituisci i valori delle variabili.

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 build. Per istruzioni sull'utilizzo di waitFor e id, vedi Configurare l'ordine dei passaggi di build.

waitFor

Utilizza il campo waitFor in un passaggio di build per specificare quali passaggi devono essere eseguiti prima del passaggio di build. 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 di essere eseguito. Per istruzioni sull'utilizzo di waitFor e id, vedi Configurazione dell'ordine dei passaggi di build.

entrypoint

Utilizza entrypoint in un passaggio di build per specificare un punto di ingresso se non vuoi 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 utilizzando una chiave di crittografia Cloud KMS. Questi valori devono essere specificati nei secret della build. Per informazioni sull'utilizzo di questo campo, consulta Utilizzo della variabile criptata nelle richieste di build.

volumes

Un volume è un volume del container Docker montato nei passaggi di build per rendere persistenti i file tra i passaggi di build. Quando Cloud Build esegue un passaggio di build, monta automaticamente un volume workspace in /workspace. Puoi specificare volumi aggiuntivi da montare nei container dei passaggi di build 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 passaggio. Se questi passaggi non hanno specificato il percorso /persistent_volume come volume permanente, il primo passaggio scriverebbe il file in quel percorso, che verrebbe eliminato prima dell'esecuzione 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 passaggio.

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 va a buon fine, la build viene completata correttamente a condizione che tutti gli altri passaggi di 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 non vanno a buon fine, lo stato della build è comunque Successful.

allowExitCodes ha la precedenza su questo campo.

Il seguente snippet di codice consente la riuscita della build 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 del passaggio di build può essere ignorato quando il passaggio restituisce un determinato codice di uscita.

Se un passaggio di build non va a buon fine con un codice di uscita corrispondente al valore che hai fornito in allowExitCodes, Cloud Build consentirà l'errore di questo passaggio di build senza che l'intera build non vada a buon fine.

Se tutti i passaggi di build non vanno a buon fine, ma ogni passaggio termina con un codice specificato nel campo allowExitCodes, la build viene comunque completata correttamente.

Tuttavia, se il passaggio di build non va a buon fine e produce un altro codice di uscita, uno che non corrisponde al valore specificato in allowExitCodes, l'intera build non andrà a buon fine.

I codici di uscita pertinenti alla tua build 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 la riuscita della build 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 impostare un limite di tempo per l'esecuzione della build. Se questo periodo di tempo trascorre, il lavoro sulla build si interrompe e lo stato della build diventa TIMEOUT.

Se timeout non è impostato, la build utilizza un timeout predefinito di 60 minuti. Il valore massimo per timeout è 24 ore. timeout è specificato in secondi, utilizzando il formato Durata, con un massimo di nove cifre frazionarie, che termina con s (ad esempio: 3.5s).

Nel seguente snippet, timeout è impostato su 660 secondi per evitare che la build scada a causa della sospensione:

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 build è in coda per un periodo di tempo superiore al valore impostato in queueTtl, la build scade e lo stato della build viene impostato su EXPIRED. Se non viene fornito alcun valore, Cloud Build utilizza il valore predefinito di 3600s (1 ora). queueTtl inizia a decorrere dal giorno createTime. queueTtl deve essere specificato in secondi con un massimo di nove cifre frazionarie, terminato da "s", ad esempio 3.5s.

Nello snippet seguente, timeout è impostato su 20s e queueTtl su 10s. queueTtl inizia a scorrere alle createTime, ovvero l'ora in cui viene richiesta la build, mentre timeout inizia a scorrere alle startTime, ovvero l'ora in cui inizia la build. Pertanto, queueTtl scadrà alle ore createTime + 10s, a meno che la build non venga avviata entro quel momento.

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

Il seguente snippet imposta un bucket di log per 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 build:

enableStructuredLogging: Consente la mappatura dei campi del log di build specificati ai campi LogEntry quando il log di build viene inviato a Logging. Ad esempio, se il log di build contiene message, il messaggio viene visualizzato in textPayload o jsonPayload.message nella voce di log risultante. I campi di log non mappabili vengono visualizzati nella voce di log jsonPayload. Per ulteriori informazioni, consulta Mappare i campi del log di compilazione ai voce di log log.

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

secretEnv: Un elenco di variabili di ambiente globali, criptate utilizzando una chiave di crittografia di Cloud Key Management Service, che saranno disponibili per tutti i passaggi di build in questa build. Questi valori devono essere specificati in 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 dell'inizio del 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 essere in conflitto con i volumi definiti in un passaggio di build. L'utilizzo di un volume globale in una build con un solo passaggio non è valido in quanto indica una richiesta di build con una configurazione errata.

pubsubTopic: Opzione per fornire un nome argomento Pub/Sub per ricevere notifiche sullo stato della build. Se non fornisci un nome, Cloud Build utilizza il nome dell'argomento predefinito cloud-builds. Il seguente snippet specifica che il nome dell'argomento Pub/Sub è my-topic:

YAML 

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/myproject/myimage', '.']
options:
    pubsubTopic: 'projects/my-project/topics/my-topic'

JSON 

{
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/myproject/myimage",
            "."
        ]
    }
    ],
    "options": {
        "pubsubTopic": "projects/my-project/topics/my-topic"
    }
}

sourceProvenanceHash: imposta l'opzione sourceProvenanceHash per specificare l'algoritmo di hashing per la provenienza dell'origine. Lo snippet seguente 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 fornisce anche due tipi di macchine virtuali aggiuntivi con 1 CPU 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ù elevata:

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 la sezione Velocizzare le build.

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

Il seguente snippet 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 trasmettere in streaming i log di build a Cloud Storage. Per impostazione predefinita, Cloud Build raccoglie i log di build al termine della build. Questa opzione specifica se vuoi trasmettere in streaming i log di build in tempo reale durante il processo di compilazione. Il seguente snippet specifica che i log di build vengono trasmessi in streaming 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 memorizza i log sia in Cloud Logging che in Cloud Storage. Puoi impostare l'opzione logging su GCS_ONLY per archiviare i log solo in Cloud Storage. Il seguente snippet specifica che i log sono 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 in modo che crei un bucket di log predefinito all'interno del tuo progetto nella stessa regione della build. Per maggiori informazioni, vedi Archiviare i log di build in un bucket di proprietà dell'utente e a livello di regione.

La seguente configurazione di build 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 build viene richiamata da un trigger, il campo dynamicSubstitutions è sempre impostato su true e non deve essere specificato nel file di configurazione della build. Se la build viene richiamata manualmente, devi impostare il campo dynamicSubstitutions su true affinché le espansioni dei parametri bash vengano interpretate durante l'esecuzione della build.

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

substitutionOption: Imposta questa opzione insieme al campo substitutions riportato di seguito per specificare il comportamento in caso di errore nei controlli di sostituzione.

pool: Imposta il valore di questo campo sul nome della risorsa del pool privato per eseguire la build. Per istruzioni sull'esecuzione di una build in un pool privato, vedi Esecuzione delle build in un pool privato.

requestedVerifyOption: imposta il valore di requestedVerifyOption su VERIFIED per attivare e verificare la generazione di attestazioni e metadati di provenienza per la build. Una volta impostate, 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 fase di build. Le sostituzioni sono utili per le variabili il cui valore non è noto fino al momento della build o per riutilizzare una richiesta di build esistente con valori di variabile diversi. Per impostazione predefinita, la build 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". È impostata l'opzione di sostituzione ALLOW_LOOSE, il che significa che la build 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 Sostituzione dei valori delle variabili.

tags

Utilizza il campo tags per organizzare le build in gruppi e per filtrarle. 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 saperne di più, consulta Utilizzo dei secret.

secrets

Secret accoppia un insieme di variabili di ambiente segrete contenenti valori criptati con la chiave Cloud KMS da utilizzare per decriptare il valore.

serviceAccount

Utilizza questo campo per specificare il account di servizio IAM da utilizzare in fase di build. Per ulteriori informazioni, vedi Configurazione dei service account specificati dall'utente.

Non puoi specificare il service account Cloud Build legacy in questo campo.

images

Il campo images nel file di configurazione della build specifica una o più immagini Docker Linux da inviare da Cloud Build ad Artifact Registry. Potresti avere una build che esegue attività senza produrre immagini Docker Linux, ma se crei immagini e non le carichi nel registro, le immagini vengono eliminate al completamento della build. Se un'immagine specificata non viene prodotta durante la build, la build non andrà a buon fine. Per ulteriori informazioni sulla memorizzazione delle immagini, consulta Memorizzare gli artefatti in Artifact Registry.

La seguente configurazione della build 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 build specifica uno o più artefatti non container da archiviare in Cloud Storage. Per saperne di più sull'archiviazione di artefatti non containerizzati, consulta Archivia gli artefatti di build in Cloud Storage.

La seguente configurazione di build imposta il campo artifacts per archiviare il pacchetto Go creato 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"
        ]
      }
    }
}

goModules

Il campo goModules consente di caricare moduli Go non container nei repository Go in Artifact Registry. Per ulteriori informazioni, vedi Creare e testare applicazioni Go.

Il campo repository_location specifica il repository Artifact Registry in cui archiviare i pacchetti. Il campo module_path specifica la directory locale che contiene il modulo Go da caricare. Questa directory deve contenere un file go.mod.

Ti consigliamo di utilizzare un percorso assoluto per il valore di module_path. Puoi utilizzare . per fare riferimento alla directory di lavoro corrente, ma il campo non può essere omesso o lasciato vuoto. Per ulteriori istruzioni sull'utilizzo di module_path, consulta Creare e testare applicazioni Go.

La seguente configurazione di build imposta il campo goModules per caricare il modulo in example.com/myapp nel repository Artifact Registry quickstart-go-repo:

YAML 

artifacts:
  goModules:
    - repositoryName: 'quickstart-go-repo'
      repositoryLocation: 'us-central1'
      repositoryProjectId: 'argo-local-myname'
      sourcePath: '/workspace/myapp'
      modulePath: 'example.com/myapp'
      moduleVersion: 'v1.0.0'

JSON 

{
  "artifacts": {
    "goModules": [
     {
      "repositoryName": "quickstart-go-repo",
      "repositoryLocation": "us-central1",
      "repositoryProjectId": "argo-local-myname",
      "sourcePath": "/workspace/myapp",
      "modulePath": "example.com/myapp",
      "moduleVersion": "v1.0.0"
     }
    ]
  }
}

mavenArtifacts

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

La seguente configurazione di build imposta il campo mavenArtifacts per caricare il file compresso 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 su Artifact Registry. Per maggiori informazioni, vedi Creare e testare applicazioni Python.

La seguente configurazione di build 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 i pacchetti npm creati nei repository supportati in Artifact Registry. Devi fornire valori per repository e packagePath.

Il campo repository specifica il repository Artifact Registry in cui archiviare i 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 di packagePath. Puoi utilizzare . per fare riferimento alla directory di lavoro corrente, 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 pacchetto npm nella directory /workspace/my-pkg nel 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 gcloud CLI o trigger di build, puoi utilizzare un Dockerfile senza un file di configurazione di build separato. Se vuoi apportare ulteriori modifiche alle build Docker, puoi fornire un file di configurazione della build oltre al Dockerfile. Per istruzioni su come creare un'immagine Docker utilizzando un Dockerfile, consulta la Guida rapida: crea.

Rete Cloud Build

Quando Cloud Build esegue ogni passaggio di build, collega il container del passaggio 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 utilizzando gcloud in un passaggio docker, utilizza il flag --network nel passaggio docker build:

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