Creare un file di trigger

Questa pagina descrive i passaggi per creare un file YAML dei trigger in Secure Source Manager. Un file di trigger può essere utilizzato per automatizzare le build in base agli eventi push e pull request in un repository Secure Source Manager.

Per scoprire di più sui campi che puoi includere in un file di trigger, leggi Schema del file di trigger.

Prima di iniziare

  1. Crea un'istanza Secure Source Manager.
  2. Crea un repository Secure Source Manager.
  3. Leggi lo schema del file dei trigger per scoprire i campi che puoi includere in un file dei trigger.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare un file di trigger, chiedi all'amministratore di concederti i seguenti ruoli IAM:

Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Crea un file di configurazione Cloud Build

I trigger di Secure Source Manager richiedono di specificare un file di configurazione della build per ogni trigger.

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.

Crea i file di configurazione di compilazione nel ramo o nei rami da cui vuoi eseguire la compilazione. Per creare i file di configurazione di compilazione, segui le istruzioni in Crea un file di configurazione di compilazione.

Creare un file di trigger

Il file di configurazione dei trigger deve essere creato nel ramo predefinito del repository.

Per creare un file di configurazione dei trigger:

  1. Nel repository locale o nell'interfaccia web di Secure Source Manager, passa al branch predefinito.

  2. Crea un file denominato .cloudbuild/triggers.yaml.

  3. Configura il trigger nel file .cloudbuild/triggers.yaml:

    triggers:
- name: TRIGGER_NAME
  project: PROJECT_ID
  configFilePath: CLOUD_BUILD_CONFIG_PATH
  eventType: EVENT_TYPE
  ignoredGitRefs: IGNORED_GIT_REFS
  includedGitRefs: INCLUDED_GIT_REFS
  serviceAccount: SERVICE_ACCOUNT
  includedFiles: INCLUDED_FILES
  ignoredFiles: IGNORED_FILES
  disabled: DISABLED_BOOL
  substitutions:
    _VARIABLE_NAME: VARIABLE_VALUE
    OVERRIDE_VARIABLE_NAME: OVERRIDE_VARIABLE_VALUE

    Sostituisci quanto segue:

    • TRIGGER_NAME con un nome per l'attivatore. I nomi dei trigger possono contenere solo caratteri alfanumerici e trattini e non possono iniziare o terminare con un trattino. I nomi dei trigger devono essere inferiori a 64 caratteri.
    • PROJECT_ID con l'ID progetto Google Cloud in cui hai attivato Cloud Build. Questo campo è facoltativo. Il valore predefinito è il progetto Secure Source Manager.
    • CLOUD_BUILD_CONFIG_PATH con il percorso del file di configurazione di Cloud Build che vuoi utilizzare per questo trigger. Questo campo è facoltativo. Il valore predefinito è .cloudbuild/cloudbuild.yaml

    • EVENT_TYPE con il tipo di evento che vuoi attivare la build. Le opzioni sono le seguenti:

      • push per attivare il push ai rami specificati
      • pull_request per attivare una richiesta di pull per i rami specificati

      Questo campo è facoltativo. Il valore predefinito è push.

    • INCLUDED_GIT_REFS con un formato di espressione regolare RE2 facoltativo che corrisponde ai riferimenti Git che vuoi attivare per una build. Il valore predefinito è vuoto. Un valore vuoto indica che non sono presenti limitazioni.

    • IGNORED_GIT_REFS con un'espressione regolare facoltativa che utilizza il formato dell'espressione regolare RE2 che corrisponde ai riferimenti Git per cui non vuoi attivare una build. Il valore predefinito è vuoto. Un valore vuoto indica che non sono previste limitazioni. Il campo ignoredGitRefs viene controllato prima del campo includedGitRefs. Per ulteriori informazioni su questi campi, consulta la sezione Schema del file dei trigger.

    • SERVICE_ACCOUNT con il service account Cloud Build da utilizzare per la build nel formato projects/PROJECT_ID/serviceAccounts/ACCOUNT. Sostituisci ACCOUNT con l'indirizzo email o l'ID univoco del account di servizio. Come best practice, configura un service account specificato dall'utente. Il account di servizio Cloud Build legacy non può essere utilizzato a causa dei suoi limiti.

    • INCLUDED_FILES con un'espressione regolare facoltativa in formato RE2 che corrisponde ai file per cui vuoi attivare una build.

      Se uno dei file modificati non corrisponde al campo filtro ignoredFiles e i file modificati corrispondono al campo filtro includedFiles, viene attivata una build. Il valore predefinito è vuoto. Un valore vuoto indica che non sono presenti limitazioni.

    • IGNORED_FILES con un'espressione regolare facoltativa in formato RE2 che corrisponde ai file per i quali non vuoi attivare una build.

      Se tutti i file modificati in un commit corrispondono a questo campo del filtro, una build non viene attivata. Il valore predefinito è vuoto. Un valore vuoto indica che non sono presenti restrizioni.

    • DISABLED_BOOL con true per disattivare il trigger oppure false per attivarlo. Questo campo è facoltativo. Il valore predefinito è false.

    • VARIABLE_NAME con il nome di una variabile che vuoi introdurre nel file dei trigger.

    • VARIABLE_VALUE con il valore della variabile.

    • OVERRIDE_VARIABLE_NAME con il nome della variabile di sostituzione predefinita di Secure Source Manager. Per informazioni sulle variabili di sostituzione predefinite disponibili, consulta la sezione delle sostituzioni dello schema del file dei trigger.

    • OVERRIDE_VARIABLE_VALUE con il valore con cui vuoi sostituire il valore predefinito della variabile di sostituzione predefinita.

  4. Esegui il commit del file di configurazione dell'attivatore nel branch predefinito.

    Dopo il commit del file di trigger, Secure Source Manager attiva le build in base alla configurazione nel file di trigger.

    Secure Source Manager legge i file di configurazione e la SHA del commit o il riferimento Git associato dei seguenti tipi di eventi:

    • Per gli eventi push, Secure Source Manager leggerà lo SHA del commit o il riferimento Git al termine del push.
    • Per gli eventi pull_request, Secure Source Manager leggerà lo SHA del commit o il riferimento Git quando le modifiche della richiesta pull vengono estratte.

Visualizzare lo stato della build

Quando una build viene attivata da un evento push o pull request, lo stato del commit e della build viene visualizzato nell'interfaccia web di Secure Source Manager.

I valori possibili per lo stato della build sono i seguenti:

  • operazione riuscitaSUCCESS: la build è stata completata correttamente.
  • avvisoAVVISO: si è verificato un problema durante il tentativo di compilazione.
  • operazione non riuscitaERRORE: la build non è riuscita durante l'esecuzione.

Puoi impedire l'unione dei commit con build non riuscite in rami importanti se configuri una regola di protezione del ramo in modo che richieda un controllo dello stato riuscito dai trigger configurati nel file dei trigger. Per scoprire di più sulla protezione dei rami, leggi la panoramica della protezione dei rami.

Per visualizzare lo stato della build per un evento push:

  1. Nell'interfaccia web di Secure Source Manager, vai al tuo repository.

    Se l'evento push più recente ha attivato una build, lo stato viene visualizzato accanto all'SHA del commit. Per visualizzare i dettagli di uno stato, fai clic sullo stato.

  2. Per visualizzare lo stato della build per i commit precedenti, seleziona Commit per visualizzare la cronologia dei commit, quindi fai clic sullo stato di cui vuoi visualizzare i dettagli.

Per visualizzare lo stato della build per un evento di richiesta pull:

  1. Nell'interfaccia web di Secure Source Manager, fai clic su Pull request.

  2. Fai clic sulla richiesta di pull che vuoi visualizzare.

    Se le build sono state attivate dalla richiesta di pull, vedrai una sezione intitolata Tutti i controlli sono stati superati o Alcuni controlli hanno segnalato avvisi.

Passaggi successivi