Hinweis
Das Gem github-pages wird zwar für einige Workflows weiterhin unterstützt, allerdings ist GitHub Actions jetzt der empfohlene Ansatz für die Bereitstellung und Automatisierung von GitHub Pages-Websites.
Informationen zu Jekyll-Build-Fehlern
Wenn Sie über einen Branch veröffentlichen, versucht GitHub Pages manchmal nicht, Ihre Website zu erstellen, nachdem Sie Änderungen in die Veröffentlichungsquelle Ihrer Website gepusht haben.
- Der Benutzer, der die Änderungen gepusht hat, hat seine E-Mail-Adresse nicht verifiziert. Weitere Informationen finden Sie unter Deine E-Mail-Adresse verifizieren.
- Du führst den Push mit einem Deployment-Schlüssel durch. Wenn du das Pushen an das Repository deiner Website automatisieren möchtest, kannst du stattdessen einen Computerbenutzerin einrichten. Weitere Informationen finden Sie unter Verwalten von Bereitstellungsschlüsseln.
- Du verwendest einen CI-Dienst, der nicht zum Erstellen deiner Veröffentlichungsquelle konfiguriert ist. Beispielsweise erstellt Travis CI den
gh-pages-Branch nicht, bis du den Branch zur Liste sicherer Branches hinzufügst. Weitere Informationen zu Travis CI findest du unter Customizing the build oder in der Dokumentation deines CI-Diensts.
Hinweis
Es kann bis zu 10 Minuten dauern, bis Änderungen auf Ihrer Website veröffentlicht werden, nachdem Sie die Änderungen zu GitHub gepusht haben.
Wenn Jekyll tatsächlich versucht, Ihre Website zu erstellen, und dabei auf einen Fehler stößt, erhalten Sie eine Build-Fehlermeldung.
Weitere Informationen zur Problembehandlung bei Buildfehlern findest du unter Problembehandlung bei Jekyll-Buildfehlern für GitHub Pages-Websites.
Jekyll-Build-Fehlermeldungen mit GitHub Actions anzeigen
Standardmäßig wird Ihre GitHub Pages Website mit einer GitHub Actions Workflowausführung erstellt und bereitgestellt, es sei denn, Sie haben Ihre GitHub Pages Website so konfiguriert, dass sie ein anderes CI-Tool verwendet. Um potenzielle Buildfehler zu finden, können Sie den Workflow für Ihre GitHub Pages Website überprüfen, indem Sie den Workflow ihres Repositorys überprüfen. Weitere Informationen finden Sie unter Anzeigen des Ausführungsverlaufs eines Workflows. Weitere Informationen zum erneuten Ausführen des Workflows im Falle eines Fehlers findest du unter Erneutes Ausführen von Workflows und Jobs.
Lokales Anzeigen von Jekyll-Buildfehlermeldungen
Wir empfehlen, Ihre Website lokal zu testen. Dadurch können Sie Build-Fehlermeldungen in der Befehlszeile sehen und etwaige Build-Fehler beheben, bevor Sie Änderungen an GitHub pushen. Weitere Informationen finden Sie unter Testen Ihrer GitHub Pages-Website lokal mit Jekyll.
Anzeigen von Jekyll-Buildfehlermeldungen in deinem Pull Request
Wenn Sie von einem Branch aus veröffentlichen, können Sie beim Erstellen eines Pull Requests zum Aktualisieren Ihrer Veröffentlichungsquelle auf GitHub Build-Fehlermeldungen auf der Registerkarte Checks des Pull Requests sehen. Weitere Informationen finden Sie unter Informationen zu Statuschecks.
Wenn Sie mit einem benutzerdefinierten GitHub Actions Workflow veröffentlichen, müssen Sie ihren Workflow so konfigurieren, dass er auf dem pull_request Trigger ausgeführt wird, um Buildfehlermeldungen in Ihrer Pullanforderung anzuzeigen. In diesem Fall wird empfohlen, alle Bereitstellungsschritte zu überspringen, wenn der Workflow vom pull_request-Ereignis ausgelöst wurde. Auf diese Weise kannst du Buildfehler anzeigen, ohne die Änderungen aus deinem Pull Request auf deiner Website bereitzustellen. Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows und Auswerten von Ausdrücken in Workflows und Aktionen.
Anzeigen von Jekyll-Buildfehlern per E-Mail
Wenn Sie aus einem Branch veröffentlichen, versucht GitHub, Ihre Website zu erstellen, wenn Sie Änderungen in Ihre Veröffentlichungsquelle auf GitHub Pages pushen. Wenn der Build fehlschlägt, wird eine E-Mail an deine primäre E-Mail-Adresse gesendet.
Wenn Sie mit einem benutzerdefinierten GitHub Actions Workflow veröffentlichen, müssen Sie ihren Workflow so konfigurieren, dass er auf dem pull_request Trigger ausgeführt wird, um E-Mails zu Buildfehlern in Ihrer Pullanforderung zu erhalten. In diesem Fall wird empfohlen, alle Bereitstellungsschritte zu überspringen, wenn der Workflow vom pull_request-Ereignis ausgelöst wurde. Auf diese Weise kannst du Buildfehler anzeigen, ohne die Änderungen aus deinem Pull Request auf deiner Website bereitzustellen. Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows und Auswerten von Ausdrücken in Workflows und Aktionen.
Anzeigen von Jekyll-Buildfehlermeldungen in deinem Pull Request mit einem CI-Drittanbieterdienst
Du kannst einen Drittanbieterdienst wie Travis CI so konfigurieren, dass nach jedem Commit Fehlermeldungen angezeigt werden.
-
Füge eine Datei namens _Gemfile_zum Stamm deiner Veröffentlichungsquelle mit den folgenden Inhalten hinzu (falls diese noch nicht vorhanden ist):
source `https://rubygems.org` gem `github-pages` -
Konfiguriere das Repository deiner Website für den gewünschten Testdienst. Um beispielsweise Travis CI zu verwenden, füge eine Datei namens .travis.yml zum Stamm deiner Veröffentlichungsquelle mit den folgenden Inhalten hinzu:
language: ruby rvm: - 2.3 script: "bundle exec jekyll build" -
Du musst dein Repository eventuell mit dem Drittanbieter-Testdienst aktivieren. Weitere Informationen findest du in der Dokumentation deines Testdiensts.