Skip to main content

Fehlerbehebung von erforderlichen Statuschecks

Du kannst nach häufig auftretenden Fehlern suchen und Probleme mit erforderlichen Statusüberprüfungen beheben.

Wer kann dieses Feature verwenden?

Geschützte Branches sind in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen sowie in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team, GitHub Enterprise Cloud und GitHub Enterprise Server verfügbar. Weitere Informationen findest du unter GitHub-Pläne.

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 findest du unter REST-API-Endpunkte für Prüfungen.

Hinweis: Um erforderlich zu sein, müssen Statusprüfungen innerhalb des ausgewählten Repositorys in den letzten sieben Tagen erfolgreich abgeschlossen worden sein.

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 findest du unter Informationen zu geschützten Branches.

Hinweis: Du kannst deinen Branch auch mit dem Basisbranch unter Verwendung von Git-Rebase auf dem neuesten Stand bringen. Weitere Informationen findest du 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

Hinweis: Pull Requests, die auf dem neuesten Stand sind und die erforderlichen Statuschecks 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

Warnung: Wenn ein Workflow aufgrund von Pfadfilterung, Branchfilterung oder einer Commitnachricht übersprungen wird, verbleiben diesem Workflow zugeordnete Überprüfungen im Status „Ausstehend“. Ein Pull Request, bei dem diese Prüfungen erfolgreich sein müssen, wird vom Mergen ausgeschlossen.

Sie sollten keine Pfad- oder Branchfilterung verwenden, um Workflowausführungen zu überspringen, wenn der Workflow vor der Zusammenführung durchlaufen werden muss. Weitere Informationen findest du unter Überspringen von Workflowausführungen und unter Verfügbare Regeln für Regelsätze.

Wenn jedoch ein Auftrag in einem Workflow aufgrund einer bedingten Bedingung übersprungen wird, meldet er seinen Status als „Erfolg“. Weitere Informationen findest du unter Steuern der Auftragsausführung mithilfe von Bedingungen.

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.

Sie sollten keine Pfad- oder Branchfilterung verwenden, um Workflowausführungen zu überspringen, wenn der Workflow vor der Zusammenführung durchlaufen werden muss. Weitere Informationen findest du unter Überspringen von Workflowausführungen und unter Verfügbare Regeln für Regelsätze.

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.