{"meta":{"title":"Statusüberprüfungen","intro":"Verstehen, wie Statusprüfungen sicherstellen, dass Commits Repositorybedingungen erfüllen, Pullanforderungsüberprüfungen unterstützen und Validierungen wie Builds, Tests und Bereitstellungen verwalten.","product":"Pull Requests","breadcrumbs":[{"href":"/de/enterprise-cloud@latest/pull-requests","title":"Pull Requests"},{"href":"/de/enterprise-cloud@latest/pull-requests/reference","title":"Referenz"},{"href":"/de/enterprise-cloud@latest/pull-requests/reference/status-checks","title":"Statusüberprüfungen"}],"documentType":"article"},"body":"# Statusüberprüfungen\n\nVerstehen, wie Statusprüfungen sicherstellen, dass Commits Repositorybedingungen erfüllen, Pullanforderungsüberprüfungen unterstützen und Validierungen wie Builds, Tests und Bereitstellungen verwalten.\n\nStatusüberprüfungen zeigen an, ob Commits die für ein Repository festgelegten Bedingungen erfüllen. Sie werden in der Regel von externen Systemen erstellt, z. B. fortlaufende Integrationsbuilds, Tests, Codeüberprüfungen oder Bereitstellungsprüfungen.\n\nStatusprüfungen helfen Prüfern und Betreuern zu verstehen, ob eine Pullanforderung zum Zusammenführen bereit ist. Eine Überprüfung kann zeigen, dass die Arbeit noch ausgeführt wird, dass Änderungen die Überprüfung bestanden haben oder dass etwas Aufmerksamkeit erfordert.\n\n![Screenshot: Liste der Commits und Status](/assets/images/help/pull_requests/commit-list-statuses.png)\n\nPersonen mit Schreibberechtigungen für ein Repository können den Zustand für Statusprüfungen im Repository festlegen.\n\nWenn Statusprüfungen für eine geschützte Verzweigung erforderlich sind, müssen sie übergeben werden, bevor die Pullanforderung zusammengeführt werden kann. Siehe [Informationen zu geschützten Branches](/de/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging).\n\n> \\[!NOTE]\n> Der Status eines übersprungenen Auftrags wird als „Success“ angezeigt. Die Zusammenführung eines Pull Requests wird dadurch nicht verhindert, selbst wenn es sich um eine erforderliche Überprüfung handelt.\n\n## Typen von Statusüberprüfungen GitHub\n\nEs gibt zwei Arten von Statusüberprüfungen GitHub:\n\n| Typ | Detailebene | Erstellt von |\n| ------------------------------------------- | -------------------------------------------------- | ---------------------------------- |\n| Prüfungen | Detaillierte Ausgabe, Anmerkungen und Nachrichten. | |\n| GitHub Apps, einschließlich GitHub Actions. | | |\n| Commitstatus | Ein einfacherer Status für einen Commit. | Externe Dienste und Integrationen. |\n\n> \\[!NOTE]\n> GitHub Actions generiert Überprüfungen, keine Commit-Status, wenn Workflows ausgeführt werden.\n\nOrganisationsbesitzer und Benutzer mit Pushzugriff auf ein Repository können Überprüfungen und Commit-Status mit GitHubder API erstellen. Siehe [REST-API-Endpunkte für Prüfungen](/de/enterprise-cloud@latest/rest/checks) und [REST-API-Endpunkte für Commit-Status](/de/enterprise-cloud@latest/rest/commits/statuses).\n\n## Prüfungen\n\nPrüfungen können Buildprotokolle, Testergebnisse, Anmerkungen und Links zu weiteren Details enthalten. In einer Pullanforderung hilft Ihnen die Registerkarte **\"Prüfungen** \", zu verstehen, welche Überprüfungen ausgeführt wurden und warum eine Überprüfung bestanden oder fehlgeschlagen ist.\n\n![Screenshot der Registerkarte „Überprüfungen“ eines Pull Requests. Die Registerkarte „Überprüfungen“ und das Dropdownmenü zum Auswählen eines Commits sind dunkelorange umrandet.](/assets/images/help/pull_requests/checks-summary-for-various-commits.png)\n\n> \\[!NOTE]\n> Die Registerkarte **\"Prüfungen** \" wird nur für Pullanforderungen aufgefüllt, wenn Sie *Überprüfungen* einrichten, keine *Commit-Status für* das Repository.\n\nWenn ein Häkchen auf eine bestimmte Zeile zeigt, können Details auch auf der Registerkarte **\"Dateien** \" der Pullanforderung angezeigt werden. Dadurch können Prüfer automatisiertes Feedback mit dem geänderten Code verbinden.\n\n## Prüfungen für einzelne Commits anfordern und überspringen\n\nBei einigen Repositorys können Überprüfungen übersprungen oder für einzelne Commits angefordert werden. Dies kann hilfreich sein, wenn eine Prüfung für eine bestimmte Änderung nicht relevant ist oder wenn Prüfungen nicht automatisch angefordert werden.\n\nBei GitHub Actions Workflows können Sie workflowausführungen überspringen, die von den `push` Ereignissen `pull_request` ausgelöst werden, indem Sie eine Skip-Anweisung in Ihre Commit-Nachricht einschließen. Siehe [Überspringen von Workflowausführungen](/de/enterprise-cloud@latest/actions/how-tos/manage-workflow-runs/skip-workflow-runs).\n\nAlternativ kannst du eine der folgenden Trailer-Zeilen am Ende deiner Commitnachricht hinzufügen, um *alle* Überprüfungen für deinen Commit zu überspringen oder anzufordern.\n\n* Um Überprüfungen für einen Commit zu *überspringen*, gib deine Commit-Nachricht und eine kurze, aussagekräftige Beschreibung deiner Änderungen ein. Füge zwei leere Zeilen nach der Commitbeschreibung und vor dem schließenden Anführungszeichen hinzu, gefolgt von `skip-checks: true`:\n\n ```shell\n $ git commit -m \"Update README\n >\n >\n skip-checks: true\"\n ```\n\n* Um Überprüfungen für einen Commit *anzufordern*, geben Sie Ihre Commit-Nachricht und eine kurze, aussagekräftige Beschreibung Ihrer Änderungen ein. Füge zwei leere Zeilen nach der Commitbeschreibung und vor dem schließenden Anführungszeichen hinzu, gefolgt von `request-checks: true`:\n\n ```shell\n $ git commit -m \"Refactor usability tests\n >\n >\n request-checks: true\"\n ```\n\nStandardmäßig entfernt Git automatisch aufeinander folgende Zeilenumbrüche. Wenn Sie die Commit-Mitteilung genau so belassen möchten, wie Sie sie eingegeben haben, verwenden Sie die `--cleanup=verbatim`-Option für Ihren Commit. Weitere Informationen findest du in der Git-Dokumentation unter [`--cleanup=`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---cleanupltmodegt).\n\n## Prüfe Status und Schlussfolgerungen\n\nÜberprüft, wie sie ausgeführt werden, durch die Status, und erhält dann eine Schlussfolgerung, wenn sie fertig sind. Einige Status können nicht manuell festgelegt werden und sind reserviert für GitHub Actions.\n\n\\| Status | Description |\nGitHub Actions nur? |\n\\| --- | --- | --- |\n\\| `completed` | Die Überprüfung ist abgeschlossen und hat eine Schlussfolgerung (siehe unten). | No |\n\\| `expected` | Die Überprüfungsausführung wartet darauf, dass ein Status gemeldet wird. | Ja |\n\\| `failure` | Der Prüflauf ist fehlgeschlagen. | No |\n\\| `in_progress` | Die Überprüfung wird ausgeführt. | No |\n\\| `pending` | Die Überprüfungsausführung befindet sich am Anfang der Warteschlange, aber das [gruppenbasierte Parallelitätslimit](/de/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency) wurde erreicht. | Ja |\n\\| `queued` | Der Kontrolllauf wurde in die Warteschlange gestellt. | No |\n\\| `requested` | Der Prüflauf wurde erstellt, aber nicht in die Warteschlange verschoben. | Ja |\n\\| `startup_failure` | Die Prüfsuite ist beim Start fehlgeschlagen. Dieser Status gilt nicht für Prüfungsdurchläufe. | Ja |\n\\| `waiting` | Die Überprüfungsausführung wartet darauf, dass eine [Bereitstellungsschutzregel](/de/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) erfüllt ist. | Ja |\n\nWenn eine Überprüfung den Status `completed` aufweist, hat sie eine Schlussfolgerung. Ein erfolgreicher Abschluss bedeutet in der Regel, dass die Prüfung die Zusammenführung nicht blockiert. Ein Fehler, Timeout oder eine handlungsrelevante Schlussfolgerung bedeutet in der Regel, dass jemand die Details überprüfen muss, bevor die Pullanforderung zusammenführen kann.\n\n| Fazit | Description |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `action_required` | Die Überprüfungsausführung hat nach ihrer Beendigung die erforderlichen Aktionen bereitgestellt. Weitere Informationen findest du unter [Verwenden der REST-API zur Interaktion mit Überprüfungen](/de/enterprise-cloud@latest/rest/guides/using-the-rest-api-to-interact-with-checks#check-runs-and-requested-actions). |\n| `cancelled` | Der Prüflauf wurde abgebrochen, bevor er abgeschlossen wurde. |\n| `failure` | Der Prüflauf ist fehlgeschlagen. |\n| `neutral` | Die Überprüfung wurde mit einem neutralen Ergebnis abgeschlossen. Dies wird als Erfolg für abhängige Prüfungen GitHub Actionsbehandelt. |\n| `skipped` | Die Überprüfungsausführung wurde übersprungen. Dies wird als Erfolg für abhängige Prüfungen GitHub Actionsbehandelt. |\n| `stale` | Der Prüflauf wurde veraltet markiert GitHub , da er zu lange dauerte. |\n| `success` | Die Überprüfung wurde erfolgreich ausgeführt. |\n| `timed_out` | Der Prüflauf hat ein Timeout erreicht. |\n\n## Aufbewahrung von Schecks\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."}