Wenn du eine Prüfung und einen Status mit dem gleichen Namen hast und diesen Namen als erforderlichen Statuscheck auswählst, sind sowohl die Prüfung als auch der Status erforderlich. Weitere Informationen finden Sie unter REST-API-Endpunkte für Prüfungen.
Note
Statusprüfungen müssen innerhalb des ausgewählten Repositorys in den letzten sieben Tagen erfolgreich abgeschlossen worden sein, damit sie erforderlich sein können.
Nachdem du die erforderlichen Statusüberprüfungen aktiviert hast, muss dein Branch vor dem Zusammenführen mit dem Basisbranch auf dem neuesten Stand gebracht werden. Dadurch wird sichergestellt, dass dein Branch mit dem neuesten Code aus dem Basisbranch getestet wurde. Wenn dein Branch veraltet ist, musst du den Basisbranch in deinen Branch zusammenführen. Weitere Informationen finden Sie unter Informationen zu geschützten Branches.
Note
Du kannst deinen Branch auch mit dem Basisbranch durch Ausführen eines Git-Rebase auf dem neuesten Stand bringen. Weitere Informationen finden Sie unter Informationen zu Git-Rebase.
Du kannst lokale Änderungen erst dann an einen geschützten Branch übertragen, wenn alle erforderlichen Statuschecks bestanden sind. Ansonsten wird eine Fehlermeldung ähnlich der folgenden ausgegeben.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing
Note
Pull Requests, die auf dem neuesten Stand sind und die erforderlichen Statusüberprüfungen bestehen, können lokal gemergt und an den geschützten Branch gepusht werden. Dies kann ohne Statuschecks erfolgen, die auf dem Merge-Commit selbst ausgeführt werden.
Erforderliche Überprüfung muss für den neuesten Commit-SHA erfolgreich sein
Damit eine Pullanforderung zusammengeführt werden kann, müssen alle erforderlichen Prüfungen an die neueste Commit-SHA übergeben werden. Dadurch wird sichergestellt, dass die letzten Änderungen überprüft und die erforderlichen Standards vor dem Zusammenführen erfüllt werden. Prüfungen, die mit einem vorherigen Commit-SHA ausgelöst wurden, werden nicht als Teil der erforderlichen Prüfungen verwendet.
Konflikte zwischen dem Head-Commit und dem Test-Merge-Commit
Manchmal werden sich die Ergebnisse der Statuschecks für den Test-Merge-Commit und Head-Commit widersprechen. Wenn der Test-Merge-Commit über einen Status verfügt, muss er übergeben werden. Anderenfalls muss der Status des Head-Commit bestanden sein, bevor du den Branch zusammenführen kannst.
Wenn ein Konflikt zwischen dem Test-Merge-Commit und dem Haupt-Commit besteht, werden die Überprüfungen für den Test-Merge-Commit im Feld für den Pull Request-Status angezeigt. Im Statusfeld für den Pull Request ist dann Showing checks for the merge commit zu sehen. Weitere Informationen zu Testmergecommits findest du unter REST-API-Endpunkte für Pullanforderungen.
Handling übersprungenen, jedoch Überprüfung nötig
Warning
Wenn ein Workflow aufgrund von Pfadfilterung, Branchfilterung oder einer Commitnachricht übersprungen wird, verbleiben diesem Workflow zugeordnete Überprüfungen im Status „Pending“. Ein Pull Request, bei dem diese Prüfungen erfolgreich sein müssen, wird vom Mergen ausgeschlossen.
Wenn jedoch ein Auftrag in einem Workflow aufgrund einer bedingten Bedingung übersprungen wird, meldet er seinen Status als „Erfolg“. Weitere Informationen finden Sie unter Steuern der Auftragsausführung mithilfe von Bedingungen.
Wenn ein Auftrag fehlschlägt, werden vom fehlgeschlagenen Auftrag abhängige Aufträge übersprungen, und es wird kein Fehler gemeldet. Ein Pull Request, für den die Überprüfung erforderlich ist, darf nicht blockiert werden. Wenn du eine erforderliche Überprüfung für einen Auftrag verwenden möchtest, der von anderen Aufträgen abhängt, verwende neben needs den bedingten Ausdruck always(). Weitere Informationen dazu findest du unter Verwenden von Aufträgen in einem Workflow.
Beispiel
Das folgende Beispiel zeigt einen Workflow, der einen „erfolgreichen“ Abschlussstatus für den Auftrag build erfordert, aber der Workflow wird übersprungen, wenn der Pull Request keine Dateien im Verzeichnis scripts ändert.
name: ci
on:
pull_request:
paths:
- 'scripts/**'
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x, 14.x, 16.x]
steps:
- uses: actions/checkout@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
Aufgrund der Pfadfilterung wird ein Pull Request, der nur eine Datei im Stammverzeichnis des Repositorys ändert, diesen Workflow nicht auslösen und für das Mergen blockiert. Im Pull Request wird „Warten auf zu meldenden Status“ angezeigt.
Statusüberprüfungen mit GitHub Actions und einer Zusammenführungswarteschlange
Du musst das merge_group-Ereignis verwenden, um deinen GitHub Actions-Workflow auszulösen, wenn ein Pull Request einer Mergewarteschlange hinzugefügt wird.
Note
Wenn Ihr Repository GitHub Actions verwendet, um erforderliche Prüfungen für Pull Requests in Ihrem Repository benötigen, müssen Sie die Workflows aktualisieren, um das merge_group Ereignis als zusätzlichen Auslöser einzubeziehen. Andernfalls werden Statusüberprüfungen nicht ausgelöst, wenn du einer Mergewarteschlange einen Pull Request hinzufügst. Der Merge ist nicht erfolgreich, da die erforderliche Statusüberprüfung nicht gemeldet wird. Das merge_group-Ereignis ist von den Ereignissen pull_request und push getrennt.
Ein Workflow, der eine vom Schutz des Zielbranch verlangte Überprüfung meldet, sieht wie folgt aus:
on:
pull_request:
merge_group:
Weitere Informationen zum merge_group-Ereignis findest du unter Ereignisse zum Auslösen von Workflows.
Erforderliche Statusüberprüfungen aus unerwarteten Quellen
Es ist auch möglich, dass ein geschützter Branch eine Statusüberprüfung aus einer bestimmten GitHub App erfordert. Wenn eine Meldung wie die folgende angezeigt wird, solltest du überprüfen, ob die im Merge-Feld aufgeführte Überprüfung von der erwarteten App festgelegt wurde.
Required status check "build" was not set by the expected GitHub App.