Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beheben Sie Probleme mit dem Webhook
Problem: Der Webhook, den Sie eingerichtet haben, funktioniert Tutorial: Konfigurieren Sie einen CodeBuild-hosted GitHub Actions-Runner nicht oder Ihr Workflow-Job hängt GitHub.
Mögliche Ursachen:
-
Ihr Webhook-Workflow-Auftragsereignis löst möglicherweise keinen Build aus. Überprüfen Sie die Antwortprotokolle, um die Antwort oder Fehlermeldung einzusehen.
-
Ihre Jobs werden aufgrund ihrer Labelkonfiguration dem falschen Runner Agent zugewiesen. Dieses Problem kann auftreten, wenn einer Ihrer Jobs innerhalb eines einzelnen Workflow-Durchlaufs weniger Labels hat als ein anderer Job. Zum Beispiel, wenn Sie zwei Jobs mit den folgenden Bezeichnungen in derselben Workflow-Ausführung haben:
-
Auftrag 1:
codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} -
Aufgabe 2:
codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }},instance-size:medium
Wenn ein selbst gehosteter GitHub Actions-Job weitergeleitet GitHub wird, wird der Job an einen beliebigen Runner mit allen angegebenen Bezeichnungen des Jobs weitergeleitet. Dieses Verhalten bedeutet, dass Job 1 entweder von dem für Job 1 oder Job 2 erstellten Runner übernommen werden kann, Job 2 jedoch nur von dem für Job 2 erstellten Runner übernommen werden kann, da er ein zusätzliches Label hat. Wenn Job 1 von dem Runner aufgenommen wird, der für Job 2 erstellt wurde, bleibt Job 2 hängen, da der Job 1-Runner das
instance-size:mediumLabel nicht hat. -
Empfohlene Lösungen:
Wenn Sie mehrere Jobs innerhalb desselben Workflow-Laufs erstellen, verwenden Sie für jeden Auftrag dieselbe Anzahl von Label-Overrides oder weisen Sie jedem Job eine benutzerdefinierte Bezeichnung zu, z. B. job1 oderjob2.
Es ist die zuverlässigste Option, jedem Auftrag ein eigenes benutzerdefiniertes Label zuzuweisen. Dadurch wird sichergestellt, dass die Bezeichnungen eines Auftrags nicht Teil der Bezeichnungen eines anderen Auftrags sind. Wenn jeder Job ein Label trägt, das kein anderer Job hat, GitHub ordnet jeder Job nur dem Runner zu, der für ihn erstellt wurde, unabhängig davon, wie viele andere Overrides jeder Job verwendet. Im folgenden Arbeitsablauf hat jeder Job ein eindeutiges Label (job1undjob2). Für Job 2 gibt es zwar eine zusätzliche instance-size:medium Überschreibung, aber Job 1 kann nicht mehr dem Runner zugeordnet werden, der für Job 2 erstellt wurde, sodass keiner der Jobs hängen bleibt:
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!"
Wenn der Fehler weiterhin besteht, verwenden Sie die folgenden Anweisungen, um das Problem zu debuggen.
-
Öffnen Sie die GitHub Konsole unter
https://github.com/, um die Webhook-Einstellungen Ihres Repositorys einzusehen. Auf dieser Seite siehst du einen Webhook, der für dein Repository erstellt wurde.user-name/repository-name/settings/hooks -
Wählen Sie Bearbeiten und bestätigen Sie, dass der Webhook für die Übermittlung von Workflow-Job-Ereignissen aktiviert ist.
-
Navigieren Sie zum Tab Letzte Lieferungen, suchen Sie das entsprechende
workflow_job.queuedEreignis und erweitern Sie das Ereignis. -
Überprüfe das Feld „Labels“ in der Payload und vergewissere dich, dass es den Erwartungen entspricht.
-
Überprüfen Sie abschließend die Registerkarte „Antwort“, da diese die Antwort oder Fehlermeldung enthält, die von CodeBuild zurückgegeben wurde.
-
Alternativ können Sie Webhook-Fehler mithilfe der GitHub APIs debuggen. Sie können die letzten Lieferungen für einen Webhook mithilfe der Webhook-API „Lieferungen für ein Repository auflisten“ einsehen:
gh api \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /repos/owner/repo/hooks/hook-id/deliveriesNachdem Sie die Webhook-Lieferung gefunden haben, die Sie debuggen möchten, und die Versand-ID notiert haben, können Sie die https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#get-a-delivery-for-a-repository-webhook
Webhook-API Get a delivery for a repository verwenden. CodeBuildDie Antwort auf die Liefernutzlast des Webhooks finden Sie im Abschnitt: responsegh api \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /repos/owner/repo/hooks/hook-id/deliveries/delivery-id
Problem: Ihre GitHub Aktionen mit aktivierten https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments
Mögliche Ursachen: CodeBuild Ruft die Bereitstellung und die Umgebung ab, die dem GitHub Aktionsauftrag zugeordnet sind, falls vorhanden, um zu überprüfen, ob die Bereitstellung genehmigt wurde. Wenn CodeBuild weder die Bereitstellung noch die Umgebung abgerufen werden können, wird der CodeBuild Build möglicherweise vorzeitig ausgelöst.
Empfohlene Lösungen: Stellen Sie sicher, dass die mit Ihren CodeBuild Projekten verknüpften Anmeldeinformationen über Leseberechtigungen für die darin enthaltenen Bereitstellungen und Aktionen verfügen. GitHub