Informationen zu Jekyll-Build-Fehlern
Wenn Sie von einer Verzweigung aus veröffentlichen, wird manchmal GitHub Pages nicht versuchen, Ihre Website zu erstellen, nachdem Sie Änderungen an der Veröffentlichungsquelle Ihrer Website vorgenommen haben.
- 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.
Note
Es kann bis zu 10 Minuten dauern, bis die Änderungen an deiner Website veröffentlicht werden, nachdem du sie an GitHub Enterprise Server gepusht hast.
Wenn bei dem Versuch von Jekyll, deine Website zu erstellen, ein Fehler auftritt, wird eine Buildfehlermeldung angezeigt. Es gibt zwei Hauptarten an Jekyll-Build-Fehlermeldungen.
- Die Meldung „Page build warning“ (Seitenbuildwarnung) bedeutet, dass deine Website erfolgreich erstellt wurde, du aber Änderungen vornehmen musst, um künftige Probleme zu verhindern.
- Die Meldung „Page build failed“ (Seitenbuild fehlgeschlagen) bedeutet, dass dein Build nicht abgeschlossen werden konnte. Wenn Jekyll einen Grund dafür erkennt, enthält die Fehlermeldung eine Beschreibung der Ursache.
Weitere Informationen zur Problembehandlung bei Buildfehlern findest du unter Fehlerbehebung bei Jekyll-Build-Fehlern für GitHub Pages-Websites.
Anzeigen der Buildfehler deines Repositorys auf GitHub Enterprise Server
Du kannst Buildfehler (aber keine Buildwarnungen) für deine Website auf GitHub Enterprise Server auf der Registerkarte Einstellungen im Repository deiner Website anzeigen.
Lokales Anzeigen von Jekyll-Buildfehlermeldungen
Wir empfehlen dir, deine Website lokal zu testen. Dadurch siehst du Build-Fehlermeldungen in der Befehlszeile und kannst Build-Fehler beheben, bevor du die Änderungen zu GitHub Enterprise Server pushst. Weitere Informationen finden Sie unter GitHub Pages-Website lokal mit Jekyll testen.
Anzeigen von Jekyll-Buildfehlermeldungen in deinem Pull Request
Wenn Sie von einer Verzweigung aus veröffentlichen, können Sie, wenn Sie einen Pull Request erstellen, um Ihre Veröffentlichungsquelle auf GitHub Enterprise Server zu aktualisieren, Build-Fehlermeldungen auf der Registerkarte Überprüfungen des Pull Requests sehen. Weitere Informationen finden Sie unter Informationen zu Statuschecks.
Wenn Sie für die Veröffentlichung einen benutzerdefinierten GitHub Actions-Workflow verwenden, müssen Sie den Workflow so konfigurieren, dass er beim pull_request-Trigger ausgeführt wird, um Build-Fehlermeldungen in Ihrem Pull Request anzeigen zu können. 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 von einer Verzweigung aus veröffentlichen, versuchen GitHub Enterprise Server und GitHub Pages, Ihre Website zu erstellen, wenn Sie Änderungen an Ihrer Veröffentlichungsquelle vornehmen. Wenn der Build fehlschlägt, wird eine E-Mail an deine primäre E-Mail-Adresse gesendet.
Tip
Du erhältst nur dann eine E-Mail, wenn die Unterstützung für ausgehende E-Mails auf Ihre GitHub Enterprise Server-Instance aktiviert ist. Für weitere Informationen kontaktiere deinen Websiteadministrator.
Wenn Sie mit einem benutzerdefinierten GitHub Actions-Workflow veröffentlichen, müssen Sie Ihren Workflow so konfigurieren, dass er auf den pull_request-Trigger hin ausgeführt wird, um E-Mails über Build-Fehler in Ihrem Pull Request 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.