{"meta":{"title":"Verwenden der REST-API zur Interaktion mit Überprüfungen","intro":"Sie können die REST-API verwenden, um GitHub Apps zu erstellen, die leistungsstarke Prüfungen von Codeänderungen in einem Repository ausführen. Du kannst Apps erstellen, die Continuous Integration, Codelinting oder Codescandienste ausführen und detailliertes Feedback zu Commits bereitstellen.","product":"REST-API","breadcrumbs":[{"href":"/de/rest","title":"REST-API"},{"href":"/de/rest/guides","title":"Anleitungen"},{"href":"/de/rest/guides/using-the-rest-api-to-interact-with-checks","title":"Erste Schritte: Überprüfungen"}],"documentType":"article"},"body":"# Verwenden der REST-API zur Interaktion mit Überprüfungen\n\nSie können die REST-API verwenden, um GitHub Apps zu erstellen, die leistungsstarke Prüfungen von Codeänderungen in einem Repository ausführen. Du kannst Apps erstellen, die Continuous Integration, Codelinting oder Codescandienste ausführen und detailliertes Feedback zu Commits bereitstellen.\n\n## Übersicht\n\nAnstatt binärer Build-Status vom Typ „bestanden/nicht bestanden“ kann GitHub Apps detaillierte Statusinformationen liefern, Codezeilen mit detaillierten Informationen annotieren und Tests erneut ausführen. REST-API zum Verwalten von Prüfungen ist ausschließlich für Ihre GitHub Apps verfügbar.\n\nEin Beispiel für die Verwendung der REST-API mit einer GitHub Appfinden Sie unter [Erstellen von CI-Prüfungen mit einer GitHub-App](/de/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app#step-26-automatically-fix-rubocop-errors).\n\nSie können Status mit [geschützten Branches](/de/rest/repos#branches) verwenden, um zu verhindern, dass Pull Requests vorzeitig zusammengeführt werden. Weitere Informationen finden Sie unter [Informationen zu geschützten Branches](/de/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging).\n\n## Informationen zu Überprüfungssammlungen\n\nWenn jemand Code an ein Repository überträgt, erstellt GitHub eine Prüfsuite für den letzten Commit. Eine Prüfsuite ist eine Sammlung der [check-Ausführungen](/de/rest/checks#check-runs), die von einer einzelnen \"GitHub App\" für einen bestimmten Commit erstellt wurden. Überprüfungssammlungen fassen den Status und das Ergebnis der Überprüfungsausführungen zusammen, die in einer Sammlung enthalten sind.\n\nDie `status` können `queued`, `in_progress`, `requested`, `waiting`, `pending` oder `completed` lauten. Nur GitHub Actions kann den Status auf `requested`, `waiting` oder `pending` setzen.\n\nDer Status `completed` lässt folgende Schlussfolgerungen zu:\n\n* `action_required`\n* `cancelled`\n* `timed_out`\n* `failure`\n* `neutral`\n* `skipped`\n* `stale`\n* `startup_failure`\n* `success`\n\nDie Überprüfungssammlung meldet die `conclusion` der Überprüfungsausführung mit der höchsten Priorität in der `conclusion` der Überprüfungssammlung. Wenn beispielsweise drei Überprüfungen die Ergebnisse `timed_out`, `success` und `neutral` haben, ist das Ergebnis der Überprüfungssammlung `timed_out`.\n\nStandardmäßig erstellt GitHub automatisch eine Prüfsuite, wenn Code an das Repository übertragen wird. Dieser Standardfluss sendet das `check_suite`-Ereignis (mit `requested`-Aktion) an alle GitHub Apps mit der Berechtigung `checks:write`. Wenn Ihre GitHub App das ereignis `check_suite` empfängt, kann sie neue Überprüfungsläufe für den neuesten Commit erstellen. GitHub fügt abhängig vom Repository und dem SHA-Wert der Überprüfungsausführung automatisch neue Überprüfungsausführungen zur richtigen [Überprüfungssammlung](/de/rest/checks#check-suites) hinzu.\n\nWenn du den automatischen Standardflow nicht verwenden möchtest, hast du die Möglichkeit, beim Erstellen von Prüf-Suites zu steuern. Verwende zum Ändern der Standardeinstellungen für die Erstellung von Überprüfungssammlungen den Endpunkt [Aktualisieren von Repositoryeinstellungen für Überprüfungssammlungen](/de/rest/checks/suites#update-repository-preferences-for-check-suites). Alle Änderungen an den Einstellungen automatischer Abläufe werden im Audit-Log des Repositorys aufgezeichnet. Wenn du den automatischen Flow deaktiviert hast, kannst du eine Überprüfungssammlung mithilfe des Endpunkts [Erstellen einer Überprüfungssammlung](/de/rest/checks/suites#create-a-check-suite) erstellen. Du solltest weiterhin den Endpunkt [Erstellen einer Überprüfungsausführung](/de/rest/checks/runs#create-a-check-run) verwenden, um Feedback zu einem Commit bereitzustellen.\n\nSchreibberechtigungen für die REST-API zur Interaktion mit Überprüfungen sind nur für GitHub Apps verfügbar. OAuth apps und authentifizierte Benutzer können die Überprüfungsausführungen und Überprüfungssammlungen anzeigen, aber nicht erstellen. Wenn Sie keine GitHub App erstellent, könnten Sie die Verwendung der REST-API zur Interaktion mit [Commitstatus](/de/rest/commits#commit-statuses) interessieren.\n\nUm die Endpunkte zum Verwalten von Check-Suites zu verwenden, muss GitHub App über die Berechtigung `checks:write` verfügen und kann auch den [check\\_suite](/de/webhooks/webhook-events-and-payloads#check_suite)-Webhook abonnieren.\n\nWeitere Informationen zum Authentifizieren als GitHub-App findest du unter [Informationen zur Authentifizierung mit einer GitHub-App](/de/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app).\n\n## Informationen zu Prüfläufen\n\nEin Testlauf ist ein einzelner Test, der Teil einer Testreihe ist. Jede Ausführung enthält einen Status und ein Ergebnis.\n\nDie `status` können `queued`, `in_progress`, `requested`, `waiting`, `pending` oder `completed` lauten. Nur GitHub Actions kann den Status auf `requested`, `waiting` oder `pending` setzen.\n\nDer Status `completed` lässt folgende Schlussfolgerungen zu:\n\n* `action_required`\n* `cancelled`\n* `timed_out`\n* `failure`\n* `neutral`\n* `skipped`\n* `success`\n\nWenn ein Prüflauf länger als 14 Tage im unvollständigen Zustand ist, wird aus dem `conclusion` der Prüfausführung `stale` und er erscheint auf GitHub als veraltet mit . Nur GitHub kann Check-Ausführungen als `stale` markieren. Weitere Informationen zu den möglichen Ergebnissen einer Überprüfungsausführung findest du unter [`conclusion`-Parameter](/de/rest/checks#create-a-check-run--parameters).\n\nSobald du den [`check_suite`](/de/webhooks/webhook-events-and-payloads#check_suite)-Webhook erhältst, kannst du die Überprüfungsausführung erstellen, auch wenn die Überprüfung nicht abgeschlossen ist. Du kannst den `status` der Überprüfungsausführung aktualisieren, sobald er mit den Werten `queued`, `in_progress` oder `completed` abgeschlossen ist, und du kannst den `output` aktualisieren, sobald weitere Details verfügbar sind. Eine Überprüfungsausführung kann Zeitstempel, einen Link zu weiteren Details auf deiner externen Website, detaillierte Anmerkungen zu bestimmten Codezeilen und Informationen zur durchgeführten Analyse enthalten.\n\nAnmerkungen fügen bestimmten Codezeilen Informationen aus deinem Prüflauf hinzu. Jede Anmerkung enthält eine `annotation_level`-Eigenschaft, die `notice`, `warning` oder `failure` lauten kann. Die Anmerkung umfasst außerdem `path`, `start_line` und `end_line`, um anzugeben, auf welche Position sich die Anmerkung bezieht. Die Anmerkung umfasst eine `message`, um das Ergebnis zu beschreiben. Weitere Informationen finden Sie unter [REST-API-Endpunkte für Überprüfungsausführungen](/de/rest/checks/runs).\n\nEine Überprüfung kann auch manuell auf der benutzeroberfläche GitHub erneut ausgeführt werden. Weitere Informationen findest du unter [Statusüberprüfungen](/de/pull-requests/reference/status-checks#checks). In diesem Fall empfängt das GitHub App, das die Überprüfungsausführung erstellt hat, den Webhook [`check_run`](/de/webhooks/webhook-events-and-payloads#check_run), der eine neue Überprüfungsausführung anfordert. Wenn Sie eine Prüfausführung erstellen, ohne eine Prüfsuite zu erstellen, erstellt GitHub die Prüfsuite automatisch für Sie.\n\nSchreibberechtigungen für die REST-API zur Interaktion mit Überprüfungen sind nur für GitHub Apps verfügbar. OAuth apps und authentifizierte Benutzer können die Überprüfungsausführungen und Überprüfungssammlungen anzeigen, aber nicht erstellen. Wenn Sie keine GitHub App erstellent, könnten Sie die Verwendung der REST-API zur Interaktion mit [Commitstatus](/de/rest/commits#commit-statuses) interessieren.\n\nUm die Endpunkte zum Verwalten von Check Runs zu verwenden, muss GitHub App über die Berechtigung `checks:write` verfügen und kann außerdem den [check\\_run](/de/webhooks/webhook-events-and-payloads#check_run)-Webhook abonnieren.\n\n## Überprüfungsläufe und angeforderte Aktionen\n\nWenn Sie eine Überprüfungsausführung mit angeforderten Aktionen einrichten (nicht zu verwechseln mit GitHub Actions), können Sie in der Pull-Request-Ansicht auf GitHub eine Schaltfläche einblenden, mit der Benutzer Ihre GitHub App auffordern können, zusätzliche Aufgaben auszuführen.\n\nBeispielsweise könnte eine Codelinting-App angeforderte Aktionen verwenden, um eine Schaltfläche in einem Pull Request anzuzeigen, wodurch erkannte Syntaxfehler automatisch behoben werden können.\n\nVerwende das [`actions`-Objekt](/de/rest/checks/runs#create-a-check-run--parameters), wenn du [eine Überprüfungsausführung erstellst](/de/rest/checks#create-a-check-run), um eine Schaltfläche zu erstellen, die zusätzliche Aktionen von deiner App anfordern kann. Beispielsweise zeigt das folgende `actions`-Objekt eine Schaltfläche auf der Registerkarte **Überprüfungen** für einen Pull Request mit der Bezeichnung „Korrigieren“. Die Schaltfläche wird nach Abschluss des Prüflaufs angezeigt.\n\n```json\n\"actions\": [{\n \"label\": \"Fix this\",\n \"description\": \"Let us fix that for you\",\n \"identifier\": \"fix_errors\"\n}]\n```\n\nWenn ein Benutzer auf die Schaltfläche klickt, sendet GitHub den [`check_run.requested_action` Webhook](/de/webhooks/webhook-events-and-payloads#check_run) an Ihre App. Wenn deine App ein `check_run.requested_action`-Webhookereignis empfängt, kann sie in den Webhooknutzdaten nach dem `requested_action.identifier`-Schlüssel suchen, um zu ermitteln, welche Schaltfläche betätigt wurde, und die angeforderte Aufgabe ausführen.\n\nUnter [Erstellen von CI-Prüfungen mit einer GitHub-App](/de/apps/creating-github-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app) findest du ein detailliertes Beispiel für das Einrichten angeforderter Aktionen mit der REST-API.\n\n## Aufbewahrung von Überprüfungsdaten\n\nGitHub bewahrt Prüfdaten 400 Tage lang auf. Nach 400 Tagen werden die Daten archiviert. 10 Tage nach der Archivierung werden die Daten endgültig gelöscht.\n\nUm einen Pull Request mit Überprüfungen zusammenzuführen, die sowohl erforderlich als auch archiviert sind, musst du die Überprüfungen erneut ausführen."}