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
<a name="action-runner-troubleshoot-webhook"></a>

**Problema:** il webhook configurato [Tutorial: configura un CodeBuild-hosted GitHub Actions runner](action-runner.md) non funziona o il processo del flusso di lavoro è in sospeso. GitHub

**Possibili cause:**
+ L'evento webhook **Workflow jobs** potrebbe non riuscire ad attivare una build. Esamina i registri delle **risposte** per visualizzare la risposta o il messaggio di errore.
+ I tuoi lavori vengono assegnati al runner agent errato a causa della configurazione delle etichette. Questo problema può verificarsi quando uno dei 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 nello stesso flusso di lavoro, esegui:
  + **Job 1**: `codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`
  + **Job 2**:`codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`, `instance-size:medium`

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

**Soluzioni consigliate:**

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

L'assegnazione di un'etichetta personalizzata unica a ogni lavoro è l'opzione più affidabile. Garantisce 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, GitHub associa ogni lavoro solo al runner creato per esso, indipendentemente dal numero di altre sostituzioni utilizzate da ciascun lavoro. Nel seguente flusso di lavoro, ogni lavoro ha un'etichetta (`job1`e) univoca. `job2` Sebbene **Job 2** abbia un `instance-size:medium` override aggiuntivo, **Job 1** non può più essere abbinato al runner creato per Job **2**, quindi nessuno dei due job 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, usa 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.

1. **Scegli **Modifica** e conferma che il webhook è abilitato a fornire eventi di lavoro Workflow.**  
![Gli eventi di lavoro del flusso di lavoro sono abilitati nel tuo webhook.](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-actions-workflow-jobs.png)

1.  Vai alla scheda **Consegne recenti**, trova l'`workflow_job.queued`evento corrispondente ed espandi l'evento. 

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

1.  Infine, esamina 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.](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/github-actions-workflow-jobs-response.png)

1.  In alternativa, è possibile eseguire il debug degli errori dei webhook utilizzando GitHub le API. Puoi visualizzare le consegne recenti per un webhook utilizzando l'API [List deliveries](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook) 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 distribuzione del webhook di cui stai cercando di eseguire il debug e aver annotato l'ID di consegna, puoi utilizzare l'API webhook [Get a delivery for a](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#get-a-delivery-for-a-repository-webhook) repository. CodeBuildla risposta del payload di consegna del webhook è disponibile 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 Actions with [deployment protection](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments) rules abilitati vengono compilati CodeBuild prima dell'approvazione della distribuzione.

**Possibili cause:** CodeBuild recupera la distribuzione e l'ambiente associati al job GitHub Actions, se esistono, per verificare se sono approvati. 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 CodeBuild progetti dispongano delle autorizzazioni di lettura per le distribuzioni e le azioni interne. GitHub