Creazione di repository da GitHub Enterprise

Cloud Build ti consente di creare trigger su un'istanza GitHub Enterprise. Questa pagina spiega come utilizzare gli attivatori GitHub Enterprise per richiamare le build in risposta a commit o richieste di pull da un repository GitHub Enterprise.

Scopri di più sui trigger di Cloud Build e sui repository Cloud Build.

Prima di iniziare

  • Enable the Cloud Build and Secret Manager APIs.

    Enable the APIs

Creazione di un trigger GitHub Enterprise

Questa sezione spiega come creare un trigger e collegarlo all'installazione di GitHub Enterprise. Se vuoi utilizzare gli attivatori di GitHub Enterprise in una rete privata, consulta Creare repository da GitHub Enterprise in una rete privata per ulteriori istruzioni.

Console

Per creare trigger di GitHub Enterprise utilizzando la console Google Cloud:

  1. Apri la pagina Trigger nella console Google Cloud.

    Apri la pagina Trigger

  2. Seleziona il tuo progetto dal menu a discesa del selettore progetti nella parte superiore di della pagina.

  3. Fai clic su Apri.

  4. Fai clic su Crea trigger.

  5. Inserisci le seguenti impostazioni di trigger:

    • Nome: inserisci un nome per l'attivatore.

    • Regione: seleziona la regione per il tuo trigger.

      • Se il file di configurazione di compilazione associato al trigger specifica un pool privato, Cloud Build utilizza il pool per eseguire la build. In questo caso, la regione specificata nell'attivatore deve corrispondere a quella in cui hai creato il pool privato.
      • Se il file di configurazione di compilazione associato al trigger non specifica un pool privato, Cloud Build utilizza il valore predefinito pool per eseguire la build nella stessa regione come trigger.

    • (Facoltativo) Descrizione: inserisci una descrizione per l'attivatore.

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

      • Push a un ramo: imposta l'attivatore per avviare una build quando vengono eseguiti commit a un determinato ramo.

      • Invia nuovo tag: imposta l'attivatore in modo da avviare una build sui commit che contengono un determinato tag.

      • Richiesta di pull: imposta l'attivatore per avviare una compilazione su commit di una richiesta di pull.

    • Origine: seleziona 2ª generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato. Per connettere un nuovo repository, vedi Connettersi a un repository GitHub Enterprise.

      • Ramo o Tag: specifica un'espressione regolare con il ramo o valore del tag da far corrispondere. Per informazioni sulla sintassi accettabile delle espressioni regolari, consulta la pagina sulla sintassi RE2.

      • Controllo dei commenti: se hai selezionato Richiesta pull (solo app GitHub) Evento, scegli una delle seguenti opzioni per controlla se una build verrà eseguita automaticamente dal trigger:

        • Obbligatorio, tranne che per proprietari e collaboratori: quando viene eseguito un pull una richiesta viene creata o aggiornata da un proprietario o un collaboratore del repository, le build verranno eseguite automaticamente dal trigger. Se un collaboratore esterno avvia l'azione, le build verranno eseguite solo dopo che un proprietario o un collaboratore avrà commentato /gcbrun la richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata dal proprietario o collaboratore di un repository con /gcbrun nella descrizione o nel commento della richiesta di pull, le build vengono eseguite automaticamente dal trigger. Quando una richiesta di pull viene creata o aggiornata da qualsiasi collaboratore, le build verranno eseguite solo dopo che un proprietario o un collaboratore avrà commentato /gcbrun la richiesta di pull.

        • Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un , le build verranno eseguite automaticamente dai trigger.

    • File inclusi (facoltativo): modifiche che interessano almeno uno di questi file richiamano una build.

    • (Facoltativo) File ignorati: le modifiche che interessano solo i file ignorati verranno non richiamano una build.

    • Configurazione: seleziona il file di configurazione della build nel tuo repository remoto o crea un file di configurazione della build in linea da utilizzare per la build.

      • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
        • Rilevato automaticamente: Cloud Build rileva automaticamente il tuo tipo di configurazione se nel repository è presente un cloudbuild.yaml o Dockerfile.
        • File di configurazione di Cloud Build (yaml o json): Utilizza un file di configurazione della build per la tua configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpacks: utilizza buildpacks per la tua 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 o della directory Dockerfile e un nome per l'immagine risultante. Se la configurazione è Dockerfile, puoi facoltativamente specificare un timeout per la build. Dopo aver fornito l'attributo Dockerfile e il nome dell'immagine, visualizzerai un anteprima del comando docker build che verrà eseguita dalla build.
        • In linea: 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 della configurazione di compilazione nella console Google Cloud utilizzando la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • (Facoltativo) Variabili di sostituzione: se hai selezionato la colonna Cloud Build di configurazione come opzione di configurazione della build, puoi scegliere di definire specifiche di sostituzione utilizzando questo campo. Ad esempio, supponiamo che tu stia creando diversi trigger in cui ogni trigger esegue il deployment dell'app in un ambiente specifico. Puoi specificare che il deployment dell'app viene eseguito in un ambiente nella configurazione della build e poi utilizza questo campo per definire le variabili di sostituzione specificando nel quale deve essere eseguito il deployment del trigger. Per informazioni su come specificare i valori di sostituzione nei file di configurazione di compilazione, consulta Sostituzioni dei valori delle variabili.

    • (Facoltativo) Log di build: seleziona la casella per inviare i log di build a GitHub. Per scoprire come visualizzare i log di build, consulta Visualizzazione dei log di build.

    • Account di servizio: seleziona l'account di servizio da utilizzare per richiamare il trigger. Se non selezioni un account di servizio, viene utilizzato il service account Cloud Build predefinito.

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

Per creare trigger GitHub utilizzando i comandi gcloud, consulta i comandi gcloud per la creazione di un trigger di compilazione.

gcloud

Per creare trigger di GitHub Enterprise utilizzando i comandi gcloud, esegui il seguente comando:

gcloud builds triggers create github \
  --name=TRIGGER_NAME \
  --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
  --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
  --build-config=BUILD_CONFIG_FILE \
  --region=REGION

Dove:

  • TRIGGER_NAME è il nome del tuo trigger.
  • PROJECT_ID è l'ID del tuo progetto Google Cloud.
  • REGION è la regione dell'attivatore.
  • CONNECTION_NAME è il nome della connessione GitHub Enterprise.
  • REPO_NAME è il nome del tuo repository
  • BRANCH_PATTERN è il nome del ramo nel repository su cui invocare la compilazione.
  • TAG_PATTERN è il nome del tag in su cui richiamare la build.
  • BUILD_CONFIG_FILE è il percorso del file di configurazione della build.

Condivisione dei dati

I dati inviati a GitHub Enterprise da Cloud Build ti aiutano a identificare gli trigger per nome e a visualizzare i risultati della build su GitHub Enterprise.

I seguenti dati sono attualmente condivisi tra Cloud Build e GitHub Enterprise:

  • ID progetto Cloud
  • Nome trigger
  • Log di build

Se hai creato trigger prima di agosto 2020, la condivisione dei dati potrebbe non essere attivata per il tuo progetto. Puoi attivare la condivisione dei dati per tutti gli trigger GitHub Enterprise nel tuo progetto facendo clic su Attiva nella scheda Condivisione dei dati di Cloud Build.

Se hai controlli di stato obbligatori abilitata per un repository GitHub Enterprise, l'abilitazione della condivisione dei dati potrebbe interrompere temporaneamente di controllo dello stato. Puoi modificare le configurazioni di controllo dello stato per cercare il nome dell'attivatore:

  • Disattivazione di eventuali controlli obbligatori specifici di Cloud Build nel repository GitHub Enterprise
  • Assicurarsi che la condivisione dei dati sia abilitata in Cloud Build
  • Eseguire una nuova build in Cloud Build che pubblichi gli stati nel tuo repository
  • Riattivazione dei controlli dello stato richiesti con selezione del nome del trigger

Passaggi successivi