Informationen zu Jekyll-Build-Fehler für GitHub Pages-Websites

Wenn beim Erstellen deiner GitHub Pages-Website mit Jekyll lokal oder auf GitHub ein Fehler auftritt, erhältst du eine Fehlermeldung mit weiteren Informationen.

Wer kann dieses Feature verwenden?

GitHub Pages ist in öffentlichen Repositorys mit GitHub Free und GitHub Free für Organisationen sowie in öffentlichen und privaten Repositorys mit GitHub Pro, GitHub Team, GitHub Enterprise Cloud und GitHub Enterprise Server verfügbar. Weitere Informationen findest du unter GitHub-Pläne.

GitHub Pages verwendet nun GitHub Actions zur Ausführung des Jekyll-Builds. Wenn Sie einen Zweig als Quelle Ihres Builds verwenden, muss GitHub Actions in Ihrem Repository aktiviert sein, wenn Sie den eingebauten Jekyll-Workflow verwenden möchten. Wenn GitHub Actions nicht verfügbar oder deaktiviert ist, können Sie alternativ eine .nojekyll-Datei zum Stamm Ihrer Quellverzweigung hinzufügen, um den Jekyll-Erstellungsprozess zu umgehen und den Inhalt direkt bereitzustellen. Weitere Informationen zur Aktivierung von GitHub Actions findest du unter Verwalten von GitHub Actions-Einstellungen für ein Repository.

In diesem Artikel

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.

  • Der Benutzer, der die Änderungen gepusht hat, hat seine E-Mail-Adresse nicht verifiziert. Weitere Informationen findest du 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.

Note

Es kann bis zu 10 Minuten dauern, bis die Änderungen an deiner Website, die du per Push an GitHub übertragen hast, veröffentlicht werden.

Wenn bei dem Versuch von Jekyll, deine Website zu erstellen, ein Fehler auftritt, wird eine Buildfehlermeldung angezeigt.

Weitere Informationen zur Problembehandlung bei Buildfehlern findest du unter Fehlerbehebung bei Jekyll-Build-Fehlern für GitHub Pages-Websites.

Anzeigen von Jekyll-Buildfehlermeldungen mit GitHub Actions

Deine GitHub Pages-Website wird standardmäßig mit einer GitHub Actions-Workflowausführung erstellt und bereitgestellt, es sei denn, du hast deine GitHub Pages-Website so konfiguriert, dass ein anderes CI-Tool verwendet wird. Du kannst die Workflowausführung deiner GitHub Pages-Website überprüfen, um nach möglichen Buildfehler zu suchen, indem du die Workflowausführungen deines Repositorys überprüfst. 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

Es wird empfohlen, die Website lokal zu testen. Dadurch werden in der Befehlszeile Buildfehlermeldungen angezeigt, und du kannst eventuelle Buildfehler beheben, bevor du die Änderungen per Push an GitHub überträgst. Weitere Informationen finden Sie unter GitHub Pages-Website lokal mit Jekyll testen.

Anzeigen von Jekyll-Buildfehlermeldungen in deinem Pull Request

Bei der Veröffentlichung von einem Branch werden auf der Registerkarte Checks des Pull Requests Buildfehlermeldungen angezeigt, wenn du einen Pull Request erstellst, um deine Veröffentlichungsquelle auf GitHub zu aktualisieren. 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

Bei der Veröffentlichung von einem Branch versucht GitHub Pages, deine Website zu erstellen, wenn du Änderungen an deiner Veröffentlichungsquelle per Push an GitHub überträgst. 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 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.

  1. 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`

  2. 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"

  3. Du musst dein Repository eventuell mit dem Drittanbieter-Testdienst aktivieren. Weitere Informationen findest du in der Dokumentation deines Testdiensts.