Crea e gestisci i trigger di build

Console

1. Apri la pagina Trigger nella console Google Cloud .

   Apri la pagina Trigger

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo Google Cloud progetto.

3. Fai clic su Crea trigger.

4. Inserisci le seguenti impostazioni del trigger:

   • Nome: inserisci un nome per il trigger.

   • Regione: seleziona la regione per il trigger.

     Se il file di configurazione della build associato al trigger specifica un pool privato, la regione selezionata per il trigger deve corrispondere alla regione del pool privato.

     Se selezioni global come regione, Cloud Build utilizza la regione specificata nel file di configurazione della build per eseguire la build. Può trattarsi della regione del pool privato, se specifichi un pool privato nel file di configurazione di compilazione, o del pool predefinito globale se non specifichi un pool privato.

   • (Facoltativo) Descrizione: inserisci una descrizione per il trigger.

   • Evento: seleziona l'evento del repository per richiamare il trigger.

     • Push a un ramo: imposta il trigger per avviare una build quando vengono eseguiti commit a un ramo specifico.

     • Push new tag: imposta il trigger per avviare una build sui commit che contengono un tag specifico.

     • Richiesta di pull: imposta il trigger per avviare una build in base ai commit di una richiesta di pull.

   • Origine: seleziona 1ª generazione o 2ª generazione come origine. Puoi connettere repository solo da GitHub e GitHub Enterprise quando selezioni 2ª generazione come origine. Per saperne di più, consulta Repository Cloud Build.

     • Repository: seleziona un repository dall'elenco di repository disponibili. Per connettere un nuovo repository, consulta Connessione ai repository di origine.

     • Branch o Tag: specifica un'espressione regolare con il valore del ramo o del tag da soddisfare. Le barre (/) non possono essere utilizzate nei tag. Per ulteriori informazioni sulla sintassi accettabile delle espressioni regolari, vedi sintassi RE2.

       Quando viene eseguita la build, Cloud Build copia i contenuti del repository in /workspace, la directory di lavoro predefinita per Cloud Build. Scopri di più sulle directory di lavoro nella pagina Panoramica della configurazione di build.

       Per consentire solo le build da origini specifiche, imposta un criterio dell'organizzazione per le integrazioni consentite (constraints/cloudbuild.allowedIntegrations) in modo da negare l'interazione con l'origine definita nel trigger. Il criterio dell'organizzazione esegue l'override del trigger e la build non viene eseguita. Per saperne di più, consulta Gate builds on organization policy per il tuo progetto.

   • File inclusi (facoltativo): le modifiche che interessano almeno uno di questi file attiveranno una build. Puoi utilizzare stringhe glob per specificare più file con caratteri jolly. I caratteri jolly accettabili includono i caratteri supportati da Go Match, ** e alternanza.

   • File ignorati (facoltativo): le modifiche che interessano solo i file ignorati non richiameranno una build. Puoi utilizzare le stringhe glob per specificare più file con caratteri jolly. I caratteri jolly accettabili includono i caratteri supportati da Go Match, ** e alternanza.

     Se specifichi un file sia in File inclusi che in File ignorati, le modifiche apportate a questo file non attiveranno una build. Supponiamo che tu specifichi **/README.md in Ignored files per ignorare README.md in qualsiasi directory e specifichi src/* in Included files per avviare una build in base alle modifiche apportate a qualsiasi file nella cartella src/. Ora, se apporti una modifica a src/README.md, Cloud Build non avvierà una build. Ogni volta che esegui il push di una modifica all'origine, Cloud Build esamina i file modificati per individuare i file inclusi e ignorati per determinare se deve essere richiamata una build:

     • Se esegui il push di una modifica al repository in un ramo esistente, Cloud Build esamina i file modificati tra il commit che hai appena eseguito il push e il commit a cui puntava in precedenza il ramo.
     • Se il repository è Cloud Source Repositories ed esegui il push di una modifica a un ramo appena creato, Cloud Build considera tutti i file del repository come modificati.
     • Se elimini un ramo, Cloud Build non avvia una build.

   • Configurazione: seleziona il file di configurazione della build che si trova nel repository remoto o crea un file di configurazione della build incorporato da utilizzare per la build.

     • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
       • File di configurazione di Cloud Build (yaml o json): utilizza un file di configurazione della build per la configurazione.
       • Dockerfile: utilizza un Dockerfile per la configurazione.
       • Buildpacks: utilizza i buildpack per la configurazione.

     • Posizione: specifica la posizione della configurazione.

       • Repository: se il file di configurazione si trova nel repository remoto, fornisci la posizione del file di configurazione della build, della directory Dockerfile o della directory dei buildpack. Se il tipo di configurazione della build è Dockerfile o un buildpack, devi fornire un nome per l'immagine risultante e, facoltativamente, un timeout per la build. Dopo aver fornito il nome dell'immagine Dockerfile o del buildpack, vedrai un'anteprima del comando docker build o pack che verrà eseguito dalla build.
       • (Facoltativo) Variabili di ambiente Buildpack: se hai selezionato buildpacks come tipo di configurazione, fai clic su Aggiungi variabile di ambiente Pack per specificare le variabili di ambiente e i valori di Buildpack. Per scoprire di più sulle variabili di ambiente buildpack, consulta Variabili di ambiente.

       • Inline: se hai selezionato File di configurazione di Cloud Build (yaml o json) come opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nella consoleGoogle Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per salvare la configurazione della build.

   • Utilizza pool privato: questo campo viene visualizzato se hai selezionato Dockerfile come opzione Configurazione. Seleziona questa casella di controllo se esegui la build in un pool privato.

   • Pool privato: se hai selezionato Utilizza pool privato, specifica il nome risorsa del pool privato del modulo projects/WORKERPOOL_PROJECT_ID/locations/REGION/workerPools/WORKERPOOL_ID.

   • (Facoltativo) Variabili di sostituzione: se hai selezionato il file di configurazione Cloud Build come opzione di configurazione della build, puoi scegliere di definire variabili di sostituzione specifiche del trigger utilizzando questo campo. Ad esempio, supponiamo che tu stia creando più trigger in cui ogni trigger esegue il deployment dell'app in un ambiente specifico. Puoi specificare che la tua app venga sottoposta a deployment in un ambiente nel file di configurazione della build e poi utilizzare questo campo per definire le variabili di sostituzione che specificano l'ambiente in cui deve essere eseguito il deployment di questo trigger. Per informazioni su come specificare i valori di sostituzione nei file di configurazione della build, consulta Sostituzione dei valori delle variabili.

   • Approvazione (facoltativo): seleziona la casella per richiedere l'approvazione prima dell'esecuzione della build.

   • Service account: seleziona il account di servizio da utilizzare quando richiami il trigger. Per le build eseguite dai trigger verrà utilizzato solo il account di servizio specificato nel trigger. Se hai specificato un account di servizio nella configurazione della build, questo verrà ignorato durante l'esecuzione della build quando vengono utilizzati i trigger.

5. Fai clic su Crea per salvare il trigger di build.

gcloud

Per creare un trigger se il codice sorgente si trova in Cloud Source Repositories:

    gcloud builds triggers create cloud-source-repositories \
    --repo=REPO_NAME \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval

Dove:

• REPO_NAME è il nome del tuo repository.
• BRANCH_PATTERN è il nome del ramo nel tuo repository su cui richiamare la build.
• TAG_PATTERN è il nome del tag nel tuo repository per richiamare la build.
• BUILD_CONFIG_FILE è il percorso del file di configurazione della build.
• SERVICE_ACCOUNT è il account di servizio da utilizzare per le operazioni di trigger e build.

• (Facoltativo) Per configurare il trigger in modo che richieda l'approvazione, imposta il flag --require-approval.

Per un elenco completo dei flag, consulta il riferimento gcloud per scoprire come creare trigger per Cloud Source Repositories.

Per creare un trigger se il codice sorgente si trova in GitHub:

    gcloud builds triggers create github \
    --name=TRIGGER_NAME \
    --region=REGION \
    --repo-name=REPO_NAME \
    --repo-owner=REPO_OWNER \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval
    --include-logs-with-status

Dove:

• REGION è la regione del trigger.
• REPO_NAME è il nome del tuo repository.
• REPO_OWNER è il nome utente del proprietario del repository.
• BRANCH_PATTERN è il nome del ramo nel tuo repository su cui richiamare la build.
• TAG_PATTERN è il nome del tag nel tuo repository per richiamare la build.
• BUILD_CONFIG_FILE è il percorso del file di configurazione della build.
• SERVICE_ACCOUNT è il account di servizio da utilizzare per le operazioni di trigger e build.
• (Facoltativo) --require-approval è il flag da includere per configurare il trigger in modo che richieda l'approvazione.
• (Facoltativo) --include-logs-with-status è un flag che puoi specificare per mostrare i log di build per i tuoi repository. Questo flag è supportato per le build dai repository GitHub e GitHub Enterprise.

Per un elenco completo dei flag, consulta il riferimento gcloud su come creare trigger per GitHub.

Dopo aver eseguito il comando gcloud per creare un trigger utilizzando Cloud Source Repositories o GitHub, dovresti vedere un output simile al seguente:

  NAME         CREATE_TIME                STATUS
  trigger-001  2019-10-30T20:45:03+00:00

Console

1. Apri la pagina Trigger nella console Google Cloud .

   Apri la pagina Trigger build

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo Google Cloud progetto.

3. Individua la riga con il trigger da aggiornare.

4. Fai clic sul menu (i tre puntini verticali) posizionato all'estremità destra della riga.

5. Seleziona Modifica.

gcloud

Per aggiornare un trigger:

1. Esporta il trigger che vuoi aggiornare:

    gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Dove:

   • TRIGGER_NAME è il nome dell'attivatore.
   • EXPORT_PATH è il percorso in cui vuoi esportare il trigger. Ad esempio, puoi specificare il percorso come examples/trigger.yaml. Tieni presente che il nome file del trigger deve avere l'estensione YAML.

2. Apri il file contenente il trigger esportato.

   Il file sarà simile al seguente:

    createTime: '2022-05-26T21:56:11.830784153Z'
    filename: cloudbuild.yaml
    github:
      name: cloud-build-example
      owner: main
      push:
        branch: master
    id: 86201062-3b14-4b6a-a2fb-4ee924e8b1dd
    # remove field name and value to not show build logs
    includeBuildLogs: INCLUDE_BUILD_LOGS_WITH_STATUS
    name: trigger-001
   

3. Modifica manualmente il file per aggiornare il trigger.

   Per visualizzare i campi che puoi aggiungere o rimuovere dal trigger, consulta la risorsa trigger.

4. Salva il file.

5. Importa il trigger:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Dove:

   • IMPORT_PATH è il percorso del trigger che vuoi importare.

Il trigger di build è stato aggiornato.

Console

1. Apri la pagina Trigger nella console Google Cloud .

   Apri la pagina Trigger build

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo Google Cloud progetto.

3. Individua la riga con il trigger che vuoi disattivare.

4. Fai clic sul menu (i tre puntini verticali) posizionato all'estremità destra della riga.

5. Seleziona Disable (Disattiva).

gcloud

Per disattivare un trigger:

1. Esporta l'attivatore che vuoi disattivare:

    gcloud beta builds triggers export TRIGGER_NAME --destination=EXPORT_PATH
   

   Dove:

   • TRIGGER_NAME è il nome dell'attivatore.
   • EXPORT_PATH è il percorso in cui vuoi esportare il trigger. Ad esempio, puoi specificare il percorso come examples/trigger.yaml. Tieni presente che il nome file del trigger deve avere l'estensione YAML.

2. Apri il file contenente il trigger esportato.

   Il file sarà simile al seguente:

    createTime: '2020-02-21T20:02:50.215599013Z'
    description: Push to any branch
    filename: cloudbuild.yaml
    github:
      name: example-repo-name
      owner: example-owner
      push:
        branch: .*
    id: example-id
    name: Push-to-any-branch
    tags:
    - github-default-push-trigger
   

3. Aggiungi il campo disabled alla fine del file e imposta il valore su True.

    disabled: True
   

4. Salva il file.

5. Importa il trigger:

    gcloud builds triggers import --source=IMPORT_PATH
   

   Dove:

   • IMPORT_PATH è il percorso del trigger che vuoi importare.

Il trigger di build è ora disattivato.

Console

1. Apri la pagina Trigger nella console Google Cloud .

   Apri la pagina Trigger build

2. Nella barra degli strumenti della console Google Cloud , seleziona il tuo Google Cloud progetto.

3. Individua la riga con il trigger che vuoi eliminare.

4. Fai clic sul menu (i tre puntini verticali) posizionato all'estremità destra della riga.

5. Seleziona Elimina.

gcloud

Per eliminare un trigger, esegui questo comando:

  gcloud builds triggers delete TRIGGER_NAME

Dove:

• TRIGGER_NAME è il nome dell'attivatore.

Per un elenco completo dei flag, consulta il riferimento gcloud su come eliminare i trigger.