Problembehandlung von Regelsätzen
Wenn du in einem Repository keine Aktion ausführen kannst und den Grund dafür wissen möchtest, kannst du die aktiven Regelsätze für den entsprechenden Branch oder das entsprechende Tag anzeigen. Weitere Informationen finden Sie unter Verwalten von Regelsätzen für ein Repository.
Je nachdem, welche Regeln aktiv sind, musst du den Commitverlauf möglicherweise lokal bearbeiten, bevor du Commits per Push an den Remotebranch übertragen kannst. Wenn z. B. für einen Branch Commits signiert werden müssen, kannst du deine Signatureinstellungen aktualisieren und dann einen interaktiven Rebasevorgang für den lokalen Branch ausführen, damit der Git-Verlauf mit signierten Commits neu geschrieben wird. Weitere Informationen findest du unter Verfügbare Regeln für Regelsätze und Git rebase an der Befehlszeile verwenden.
Gelten bei einem Branch oder Tag Regeln zur Einschränkung der Commit-Metadaten, können deine Commits abgelehnt werden, wenn Teile der Commit-Metadaten einem bestimmten Muster nicht entsprechen. Beispielsweise musst du möglicherweise am Anfang der Commitnachricht eine Issuenummer hinzufügen oder den Namen eines neuen Branchs oder Tags ändern, den du an das Repository pushen möchtest. Wenn deine Commits abgelehnt werden, wird eine Meldung mit dem Muster angezeigt, dem die relevanten Metadaten entsprechen müssen. Wie bei signierten Commits musst du möglicherweise einen Rebasevorgang durchführen, um die Commits zu squashen, oder jeden Commit einzeln neu schreiben. Weitere Informationen finden Sie unter Verfügbare Regeln für Regelsätze.
Beim Verwenden von Pushregelsätzen sind pro Push maximal 1.000 Referenzupdates zulässig. Wenn dein Push diesen Grenzwert überschreitet, wird er abgelehnt. Weitere Informationen findest du unter Erstellen von Regelsätzen für ein Repository.
Zusätzlich gelten Push-Regelsätze für die API-Schnittstellen „Blob erstellen“, „Baum erstellen“ und „Dateiinhalte erstellen oder aktualisieren“ in der REST-API. Weitere Informationen findest du unter REST-API-Endpunkte für Git-BLOBs, REST API-Endpunkte für Git-Baumstrukturen und REST-API-Endpunkte für Repositoryinhalt.
Fehlerbehebung von erforderlichen Statuschecks
Beim Definieren von Statusprüfungen hängt das Namensformat vom Überprüfungstyp ab:
-
**Workflow**: Das Namensformat lautet `<job name>`. -
**Wiederverwendbarer Workflow**: Das Namensformat lautet `<job name> / <reusable job name>`. -
**Andere Überprüfungen**: Das Namensformat lautet `<check name>`.
Obligatorische Statusprüfungen berücksichtigen keine Workflow-, Matrix- oder Ereignistriggertypen.
Statusprüfungen werden nicht für Regelsätze indiziert, die oberhalb der Repository-Ebene definiert sind. Du musst manuell den genauen erwarteten Überprüfungsnamen eingeben.
Bei Regelsätzen im Auswertungsmodus wird eine Statusprüfung im Zielbranch ausgeführt, ist jedoch nicht erforderlich, bestanden zu werden.
Fehlerbehebung von Regelsatz-Workflows
Regelsatzworkflows können auf Organisationsebene oder Unternehmensebene konfiguriert werden, damit Workflows diese Überprüfung erfolgreich abschließen müssen, bevor Pull Requests gemergt werden. Weitere Informationen finden Sie unter Erstellen von Regelsätzen für Repositorys in deiner Organisation.
Regelsatzworkflows für offene Pull Requests
Wenn Sie eine Regel erstellen, während ein Pull Request geöffnet ist, wird der erforderliche Workflow nicht automatisch ausgeführt. Um den erforderlichen Workflow auszulösen, pushen Sie einen neuen Commit, aktualisieren Sie Ihre Verzweigung, oder schließen Sie den Pull Request, und öffnen Sie ihn erneut.
Unterstützte Regelsatz-Workflow-Ereignisse
Regelsatzworkflows unterstützen die Verwendung der Ereignisse pull_request, pull_request_target und merge_group. Daher müssen Sie ein oder mehrere dieser Ereignisse im on: Abschnitt des Workflows angeben, damit der Workflow von einem Regelsatz ausgeführt werden kann.
Alle Filter, die Sie für die unterstützten Ereignisse angeben, werden ignoriert – branches, branches-ignore, paths, types usw. Der Workflow wird nur und immer durch die Standardaktivitätstypen der unterstützten Ereignisse ausgelöst.
| Ereignis | Standardaktivitätstypen |
|---|---|
pull_request | opened, synchronize, reopened |
pull_request_target | opened, synchronize, reopened |
merge_group | checks_requested |
Weitere Informationen finden Sie unter Ereignisse zum Auslösen von Workflows.
Regelsatzworkflows werden nicht für Ereignisse ausgeführt, die durch GITHUB_TOKEN ausgelöst werden. Weitere Informationen finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.
Blockieren der Repositoryerstellung
Ein erforderlicher Workflow kann Menschen daran hindern, ein Repository zu erstellen, da ein Workflow nicht gegen ein Repository ausgeführt werden kann, das gerade initialisiert wird. Um dies zu umgehen, muss der Regelsatz entweder den Durchsetzungsstatus „Auswerten“ haben, oder jemand mit Umgehungsberechtigung muss das Repository erstellen und den Verzweigungsschutz umgehen.
Weitere Informationen zu Erzwingungsstatus und den Modus „Auswerten“ findest du unter Erstellen von Regelsätzen für ein Repository.
Weitere Informationen zu Umgehungsberechtigungen findest du unter Informationen zu geschützten Branches.
Verzweigungsziele in einem Regelsatz
Stellen Sie sicher, dass Ihr Regelwerk-Workflow nicht auf alle Branches im Repository ausgerichtet ist. Es sollte nur auf Branches abzielen, bei denen alle Änderungen über Pull Requests erfolgen.
Unterstütztes Verzeichnis
Überprüfen Sie, ob Ihre Workflowdatei im .github/workflows Verzeichnis vorhanden ist. Wenn Sie einen Regelsatzworkflow für pull_request Ereignisse in einem Repository ausführen möchten, das nicht das Quell-Repository ist, können Sie eine der folgenden Aktionen ausführen:
- Der Workflowdatei eine bedingte Bedingung hinzu fügen, z. B.
if: true. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions. - Vollständige Deaktivierung aller Aktionen im Quell-Repository. Weitere Informationen finden Sie unter Einstellung der GitHub Actions für ein Repository verwalten.
- Deaktivieren des einzelnen Workflows im Quell-Repository. Weitere Informationen finden Sie unter Deaktivieren und Aktivieren eines Workflows.
Verwenden des Triggers merge_group
Quell-Repositoryberechtigungen
Stellen Sie sicher, dass die Berechtigungen für das Quellrepository auf „Zugriff über Repositorys in der ORGANIZATION NAME Organisation“ festgelegt sind.
Weitere Informationen finden Sie unter Einstellung der GitHub Actions für ein Repository verwalten.
Datenschutzeinstellungen des Quell-Repositorys
Stellen Sie sicher, dass sich die Regelsatzworkflowdatei in einem Quellrepository befindet, das die gleichen oder weniger restriktiven Datenschutzeinstellungen aufweist wie die Repositorys, in denen Sie sie ausführen möchten. Ein öffentlicher Workflow kann in jedem Repository in deiner Organisation ausgeführt werden, ein interner Workflow kann auf internen und privaten Repositorys ausgeführt werden, und ein privater Workflow kann auf privaten Repositorys ausgeführt werden. Weitere Informationen finden Sie unter Workflows.
Berechtigungen zum Erstellen eines neuen Repositorys
Um ein neues Repository zu erstellen, wenn ein Regelsatzworkflow konfiguriert ist, stellen Sie sicher, dass Sie über Umgehungsberechtigungen für Ihren Regelsatz verfügen. Weitere Informationen finden Sie unter Erstellen von Regelsätzen für ein Repository.
Regeleinblicke
GitHub protokolliert keine Regeleinblicke, bis ein Pull Request zusammengeführt oder eine Zusammenführung versucht wird.
Parallelität
Stellen Sie sicher, dass der Regelsatzworkflow nicht die cancel-in-progress Parallelitätseinstellung verwendet. Weitere Informationen zum Thema Parallelität finden Sie unter Steuern der Gleichzeitigkeit von Workflows und Aufträgen.