Informationen zu Jekyll-Build-Fehlern
Sometimes, GitHub Pages will not attempt to build your site after you push changes to your site's publishing source.
- Du führst den Push mit einem Deployment-Schlüssel durch. Wenn Du Übertragungen zum Repository Deiner Website automatisieren möchtest, kannst du stattdessen einen Maschinenbenutzer einrichten. For more information, see "Managing deploy keys."
- Du verwendest einen Dienst für die fortlaufende Integration, der nicht zum Erstellen Deiner Veröffentlichungsquelle konfiguriert ist. Travis CI erstellt beispielsweise nicht den Branch
gh-pages, es sei denn, Du fügst den Branch zu einer Liste mit sicheren Branches hinzu. Weitere Informationen findest Du unter „Build anpassen“ auf Travis CI oder in der Dokumentation Deines Dienstes für die fortlaufende Integration.
Hinweis: Es kann bis zu 20 Minuten dauern, bis die Änderungen auf Ihrer Website veröffentlicht werden, nachdem Sie die Änderungen zu GitHub Enterprise Server gepusht haben.
Wenn beim Versuch von Jekyll, Deine Website zu erstellen, ein Fehler auftritt, wird eine Build-Fehlermeldung angezeigt. Es gibt zwei Hauptarten an Jekyll-Build-Fehlermeldungen.
- Eine „Page build warning“ (Seiten-Build-Warnung) bedeutet, dass Deine Website erfolgreich erstellt wurde, Du aber Änderungen vornehmen musst, um künftige Probleme zu verhindern.
- Eine Fehlermeldung „Page build failed“ (Seiten-Build 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 Behebung von Build-Fehlern findest Du unter „Behebung von Jekyll-Build-Fehlern bei GitHub Pages-Websites.“
Jekyll-Build-Fehlermeldungen anzeigen
Wir empfehlen Ihnen, Ihre Website lokal zu testen. Dadurch sehen Sie Build-Fehlermeldungen in der Befehlszeile und können Build-Fehler beheben, bevor Sie die Änderungen zu GitHub Enterprise Server pushen. Weitere Informationen findest Du unter „Deine GitHub Pages-Website lokal mit Jekyll testen.“
Wenn Sie einen Pull Request erstellen, um Ihre Veröffentlichungsquelle auf GitHub Enterprise Server zu aktualisieren, können Sie auf der Registerkarte Checks (Prüfungen) des Pull Requests die Build-Fehlermeldungen einsehen. Weitere Informationen findest Du unter „Informationen zu Statuschecks.“
Wenn Sie Änderungen zu Ihrer Veröffentlichungsquelle auf GitHub Enterprise Server pushen, versucht GitHub Pages, Ihre Website zu erstellen. Wenn der Build fehlschlägt, wird eine E-Mail an Deine primäre E-Mail-Adresse gesendet. Du erhältst auch bei Build-Warnungen E-Mail-Benachrichtigungen.
Du erhältst nur dann eine E-Mail, wenn der Support für ausgehende E-Mails auf your GitHub Enterprise Server instance aktiviert ist. Für weitere Informationen kontaktiere Deinen Websiteadministrator.
Build-Fehler (aber keine Build-Warnungen) für Ihre Website können Sie auf GitHub Enterprise Server auf der Registerkarte Settings (Einstellungen) des Repositorys Ihrer Website sehen.
Du kannst einen Drittanbieterdienst, beispielsweise Travis CI, so konfigurieren, dass nach jedem Commit Fehlermeldungen angezeigt werden.
-
Wenn Du dies noch nicht getan hast, füge eine Datei namens Gemfile in das Root-Verzeichnis Deiner Veröffentlichungsquelle ein. Die Gemfile-Datei sollte den folgenden Inhalt aufweisen:
source `https://rubygems.org` gem `github-pages` -
Konfiguriere das Repository Deiner Website für die gewünschte Test-Dienstleistung. Wenn Du beispielsweise Travis CI verwenden möchtest, füge eine Datei namens .travis.yml in das Root-Verzeichnis Deiner Veröffentlichungsquelle ein, und zwar mit folgendem Inhalt:
language: ruby rvm: - 2.3 script: "bundle exec jekyll build" -
Du musst Dein Repository allenfalls mit dem Drittanbieter-Testdienst aktivieren. Weitere Informationen findest Du in der Dokumentation Deines Test-Dienstleisters.