View a markdown version of this page

Risolvi i problemi relativi al webhook - AWS CodeBuild

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risolvi i problemi relativi al webhook

Problema: il webhook che hai impostato Tutorial: configura un CodeBuild-hosted GitHub Actions runner non funziona o il flusso di lavoro è bloccato. GitHub

Possibili cause:

  • L'evento webhook Workflow jobs potrebbe non riuscire ad attivare una build. Esamina i log delle risposte per visualizzare la risposta o il messaggio di errore.

  • I tuoi lavori vengono assegnati al runner agent errato a causa della configurazione dell'etichetta. Questo problema può verificarsi quando uno dei tuoi lavori all'interno di una singola esecuzione del flusso di lavoro ha meno etichette rispetto a un altro lavoro. Ad esempio, se hai due lavori con le seguenti etichette nella stessa esecuzione del flusso di lavoro:

    • Lavoro 1: codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}

    • Lavoro 2:codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}, instance-size:medium

    Quando si instrada un job GitHub Actions ospitato autonomamente, GitHub indirizzerà il lavoro a qualsiasi runner con tutte le etichette specificate dal lavoro. Questo comportamento significa che il Job 1 può essere prelevato dal runner creato per il Job 1 o dal Job 2, ma il Job 2 può essere prelevato solo dal runner creato per il Job 2 poiché ha un'etichetta aggiuntiva. Se il Job 1 viene raccolto dal corridore creato per il Job 2, allora il Job 2 si bloccherà poiché il Job 1 non ha l'etichetta. instance-size:medium

Soluzioni consigliate:

Quando crei più lavori all'interno della stessa esecuzione del flusso di lavoro, utilizza lo stesso numero di sostituzioni delle etichette per ogni lavoro o assegna a ciascun lavoro un'etichetta personalizzata, ad esempio job1 o. job2

Assegnare a ciascun lavoro un'etichetta personalizzata univoca è l'opzione più affidabile. Assicura che nessun set di etichette di un lavoro sia un sottoinsieme di quello di un altro lavoro. Quando ogni lavoro porta un'etichetta che nessun altro lavoro ha, assegna GitHub a ciascun lavoro solo il runner creato per esso, indipendentemente dal numero di altre sostituzioni utilizzate da ciascun lavoro. Nel flusso di lavoro successivo, ogni lavoro ha un'etichetta (job1e) univoca. job2 Sebbene il Job 2 abbia un instance-size:medium override aggiuntivo, il Job 1 non può più essere abbinato al runner creato per il Job 2, quindi nessuno dei due lavori si blocca:

name: Hello World on: [push] jobs: job1: runs-on: - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} - job1 steps: - run: echo "Hello from Job 1!" job2: runs-on: - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} - instance-size:medium - job2 steps: - run: echo "Hello from Job 2!"

Se l'errore persiste, utilizza le seguenti istruzioni per eseguire il debug del problema.

  1. Apri la GitHub console all'indirizzo https://github.com/user-name/repository-name/settings/hooks per visualizzare le impostazioni del webhook del tuo repository. In questa pagina, vedrai un webhook creato per il tuo repository.

  2. Scegli Modifica e conferma che il webhook sia abilitato a fornire eventi Workflow jobs.

    Gli eventi relativi ai job di Workflow sono abilitati nel tuo webhook.
  3. Vai alla scheda Consegne recenti, trova l'workflow_job.queuedevento corrispondente ed espandi l'evento.

  4. Controlla il campo delle etichette nel Payload e assicurati che sia come previsto.

  5. Infine, consulta la scheda Risposta, poiché contiene la risposta o il messaggio di errore restituito da CodeBuild.

    La risposta o il messaggio di errore restituito da CodeBuild.
  6. In alternativa, puoi eseguire il debug degli errori dei webhook utilizzando GitHub le API. Puoi visualizzare le consegne recenti di un webhook utilizzando l'API List deliveries for a repository webhook:

    gh api \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /repos/owner/repo/hooks/hook-id/deliveries

    Dopo aver trovato la consegna del webhook di cui desideri eseguire il debug e aver annotato l'ID di consegna, puoi utilizzare l'API webhook Get a delivery for a repository. CodeBuildla risposta del webhook al payload di consegna del webhook si trova nella sezione: response

    gh api \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /repos/owner/repo/hooks/hook-id/deliveries/delivery-id

Problema: i trigger GitHub delle azioni con le regole di protezione dell'implementazione attivate vengono generati CodeBuild prima dell'approvazione della distribuzione.

Possibili cause: CodeBuild recupera la distribuzione e l'ambiente associati al job GitHub Actions, se presenti, per verificare se la distribuzione è approvata. Se CodeBuild non riesce a recuperare la distribuzione o l'ambiente, la CodeBuild build potrebbe essere attivata prematuramente.

Soluzioni consigliate: verifica che le credenziali associate ai tuoi CodeBuild progetti dispongano delle autorizzazioni di lettura per le distribuzioni e le azioni all'interno. GitHub