Skip to main content

Enterprise Server 3.15 ist derzeit als Release Candidate verfügbar.

Problembehandlung für Regeln

Hier erfährst du, wie du die Problembehandlung bei Regelsätzen für ein Repository vornimmst.

Wer kann dieses Feature verwenden?

Regelsätze sind verfügbar in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen, und in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team und GitHub Enterprise Cloud.

Push-Regelsätze sind für den Plan GitHub Enterprise Cloud in internen und privaten Repositorys, Repositorys mit aktivierten Push-Regelsätzen und Organisationen in Ihrem Unternehmen verfügbar.

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.

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.

EreignisStandardaktivitätstypen
pull_requestopened, synchronize, reopened
pull_request_targetopened, synchronize, reopened
merge_groupchecks_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:

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 „AUTOTITEL“.