Problembehandlung bei 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 findest du 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 unter Git rebase an der Befehlszeile verwenden.
Gelten bei einem Branch oder Tag Regeln für Commitmetadaten, werden deine Commits möglicherweise abgelehnt, wenn ein Teil der Commitmetadaten nicht mit einem bestimmten Muster übereinstimmt. 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, das die relevanten Metadaten erfüllen 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 findest du 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.
Problembehandlung für Regelsatzworkflows
Regelsatzworkflows können auf Organisationsebene konfiguriert werden, so dass Workflows vor dem Zusammenführen von Pullanforderungen übergeben werden müssen. 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-Workflowereignisse
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 findest du unter Ereignisse zum Auslösen von Workflows.
Regelsatzworkflows werden nicht für Ereignisse ausgeführt, die durch GITHUB_TOKEN ausgelöst werden. Weitere Informationen findest du unter Automatische Tokenauthentifizierung.
Blockieren der Repositoryerstellung
Ein Workflow kann auch jemanden daran hindern, ein Repository zu erstellen, da ein Workflow nicht gegen ein Repository laufen 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 Erzwingstatus und den Modus „Bewertung“ finden Sie unter „Erstellen von Regelsätzen für ein Repository.“
Weitere Informationen zu Umgehungsberechtigungen finden Sie unter „Informationen zu geschützten Branches.“
Verzweigungsziele in einem Regelsatz
Stellen Sie sicher, dass Ihr Regelsatzworkflow nicht auf alle Verzweigungen im Repository ausgerichtet ist. Er sollte nur auf Verzweigungen abzielen, bei denen alle Änderungen an der Verzweigung von Pull Requests ausgeführt werden.
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 findest du unter Workflowsyntax für GitHub Actions. - Vollständige Deaktivierung aller Aktionen im Quell-Repository. Weitere Informationen findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.
- Deaktivieren des einzelnen Workflows im Quell-Repository. Weitere Informationen findest du unter Deaktivieren und Aktivieren eines Workflows.
Verwenden des Triggers merge_group
Wenn Ihr Repository GitHub Actions verwendet, um erforderliche Prüfungen durchzuführen, oder wenn Sie Workflows über Organisationsregelsätze 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.
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 findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.
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 findest du unter Informationen zu 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 findest du 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 zur Parallelität finden Sie unter „Steuern der Nebenläufigkeit von Workflows und Aufträgen“.