View a markdown version of this page

Résoudre les problèmes liés au webhook - AWS CodeBuild

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes liés au webhook

Problème : le webhook que vous avez configuré Tutoriel : Configuration d'un lanceur d' CodeBuild-hosted GitHub actions ne fonctionne pas ou votre flux de travail est suspendu GitHub.

Causes possibles :

  • Votre événement Webhook Workflow jobs ne parvient peut-être pas à déclencher une génération. Consultez les journaux des réponses pour voir la réponse ou le message d'erreur.

  • Vos tâches sont attribuées au mauvais agent de course en raison de la configuration de ses étiquettes. Ce problème peut se produire lorsque l'une de vos tâches au cours d'une même exécution de flux de travail comporte moins d'étiquettes qu'une autre tâche. Par exemple, si vous avez deux tâches portant les libellés suivants dans le même flux de travail, exécutez :

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

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

    Lors du routage d'une tâche GitHub Actions auto-hébergée, GitHub la tâche est acheminée vers n'importe quel coureur avec tous les libellés spécifiés pour la tâche. Ce comportement signifie que la tâche 1 peut être sélectionnée par le coureur créé pour la tâche 1 ou la tâche 2, mais que la tâche 2 ne peut être reprise que par le coureur créé pour la tâche 2 car elle possède une étiquette supplémentaire. Si la tâche 1 est sélectionnée par le coureur créé pour la tâche 2, la tâche 2 sera bloquée car le coureur de la tâche 1 ne possède pas l'instance-size:mediumétiquette.

Solutions recommandées :

Lorsque vous créez plusieurs tâches au cours d'une même exécution de flux de travail, utilisez le même nombre de remplacements d'étiquette pour chaque tâche ou attribuez à chaque tâche une étiquette personnalisée, telle que job1 oujob2.

L'option la plus fiable consiste à attribuer à chaque tâche sa propre étiquette personnalisée. Cela garantit qu'aucun ensemble d'étiquettes de tâche n'est un sous-ensemble de celui d'une autre tâche. Lorsque chaque tâche porte une étiquette qu'aucune autre n'a, elle GitHub associe chaque tâche uniquement au coureur créé pour elle, quel que soit le nombre d'autres remplacements que chaque tâche utilise. Dans le flux de travail suivant, chaque tâche possède une étiquette unique (job1etjob2). Bien que la tâche 2 dispose d'une instance-size:medium dérogation supplémentaire, la tâche 1 ne peut plus être associée au coureur créé pour la tâche 2, de sorte qu'aucune des tâches ne reste bloquée :

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!"

Si l'erreur persiste, suivez les instructions ci-dessous pour résoudre le problème.

  1. Ouvrez la GitHub console à l'adresse https://github.com/user-name/repository-name/settings/hooks pour afficher les paramètres du webhook de votre référentiel. Sur cette page, vous verrez un webhook qui a été créé pour votre référentiel.

  2. Choisissez Modifier et confirmez que le webhook est activé pour diffuser des événements relatifs aux tâches Workflow.

    Les événements liés aux tâches du flux de travail sont activés dans votre webhook.

  3. Accédez à l'onglet Livraisons récentes, recherchez l'workflow_job.queuedévénement correspondant et développez l'événement.

  4. Vérifiez le champ des libellés dans la charge utile et assurez-vous qu'il correspond à vos attentes.

  5. Enfin, passez en revue l'onglet Réponse, car il contient la réponse ou le message d'erreur renvoyé CodeBuild.

    La réponse ou le message d'erreur renvoyé par CodeBuild.

  6. Vous pouvez également déboguer les échecs du webhook à l'aide des API GitHub. Vous pouvez consulter les livraisons récentes pour un webhook à l'aide de l'API Webhook List deliveries for a repository : 

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

    Après avoir trouvé la diffusion du webhook que vous souhaitez déboguer et noté l'ID de livraison, vous pouvez utiliser l'API webhook Get a delivery for a repository. CodeBuildLa réponse du webhook à la charge utile de livraison du webhook se trouve dans la response section : 

    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

Problème : Vos GitHub actions lorsque les règles de protection du déploiement sont activées déclenchent des compilations CodeBuild avant que le déploiement ne soit approuvé.

Causes possibles : CodeBuild récupère le déploiement et l'environnement associés à la tâche GitHub Actions, s'ils existent, pour vérifier si le déploiement est approuvé. Si vous CodeBuild ne parvenez pas à récupérer le déploiement ou l'environnement, la CodeBuild génération peut être déclenchée prématurément.

Solutions recommandées : Vérifiez que les informations d'identification associées à vos CodeBuild projets disposent d'autorisations de lecture pour les déploiements et les actions qu'ils contiennent. GitHub