Problembehandlung für Ihre Umgebung

Erfahren Sie mehr über die Behebung von Problemen in Ihrer lokalen Umgebung und der Staging-Plattform GitHub Docs.

In diesem Artikel

Problembehandlung bei Tests, die lokal fehlschlagen, aber in CI bestehen

Wenn Sie Tests lokal ausführen und Fehler in tests/rendering/server.js rund um statische Ressourcen, Stylesheets oder das clientseitige JavaScript-Bundle erhalten, die gleichen Tests jedoch in CI auf einem PR bestehen, führen Sie den Befehl npm run build aus. Dies ist ein einmaliger Befehl, der statische Objekte lokal erstellt.

Weitere Informationen finden Sie unter Erstellen einer lokalen Umgebung.

Problembehandlung bei blockierten Stagingbereitstellungen

Wenn eine Stagingbereitstellung länger als zehn Minuten aussteht, schließen Sie die Pull Requests (ohne die Verzweigung zu löschen), und öffnen Sie sie erneut. Dadurch wird eine neue Stagingbereitstellung ausgelöst. Es wird nichts abbrechen.

Wenn dies nicht funktioniert, verwenden Sie die folgenden Befehle, um eine neue Stagingbereitstellung auszulösen, indem Sie einen leeren Commit in der Befehlszeile pushen.

git commit --allow-empty -m 'empty commit to redeploy staging'
git push

Problembehandlung bei blockierter oder hängender CI

Wenn Ihre Tests länger als eine Stunde auf „In Bearbeitung“ oder „Ausstehend“ hängen bleiben, verwenden Sie die folgenden Befehle, um CI erneut auszuführen, indem Sie einen leeren Commit in der Befehlszeile ausführen.

git commit --allow-empty -m 'empty commit to rerun CI'
git push

Problembehandlung bei Problemen mit dem lokalen Server

Wenn Sie npm start ausführen und einen Cannot find module-Fehler erhalten, versuchen Sie den folgenden Befehl, bevor Sie den Server neu starten.

npm install

Wenn das Problem dadurch nicht behoben wird, verwenden Sie den folgenden Befehl, um das node_modules-Verzeichnis zu entfernen und erneut zu installieren.

rm -rf node_modules
npm install

Fehlerbehebung bei Staging-Problemen

Wenn Probleme mit dem Staging-Server auftreten, sollten weitere Informationen zum Fehler in Ihrem Browser oder in der Befehlszeile angezeigt werden, wenn Sie die Website lokal ausführen. Checken Sie Ihre Verzweigung lokal aus, und verwenden Sie den folgenden Befehl, um den lokalen Server zu starten.

npm start

Wenn der Server ausgeführt wird, navigieren Sie zu dem problematischen Artikel https://localhost:4000 in Ihrem Browser. Der Staging-Server zeigt nur einen "Oops"-Fehler an, aber der lokale Server sollte eine Stapelüberwachung für das Debuggen anzeigen.

Wenn Sie einen Fehler sehen, der dem folgenden ähnelt, stellen Sie sicher, dass einfache Anführungszeichen in der Frontmatter ordnungsgemäß mit Escapezeichen versehen sind. Überprüfen Sie auch die Formatierung in redirect_from Blöcken. Weitere Informationen finden Sie unter Verwenden einer YAML-Titelei.

error parsing file: /Users/z/git/github/docs/content/dotcom/articles/troubleshooting-custom-domains-and-github-pages.md
(node:89324) UnhandledPromiseRejectionWarning: YAMLException: can not read a block mapping entry; a multiline key may not be an implicit key at line 4, column 14:
    redirect_from:
                 ^

Der Test „Link Checker: On PR“ meldet defekte Links auf der Seite, inklusive Bildern. Wenn defekte Links vorhanden sind, schlägt der Test fehl und in der Detailansicht des Tests werden entweder TitleFromAutotitleError Fehler angezeigt, die nur die URL des defekten Links melden, oder ein aussagekräftigerer Bericht, der auch die Seite auflistet, die den fehlerhaften Link enthält.

Wenn der Fehler nicht den Speicherort des fehlerhaften Links enthält, müssen Sie das docs-Repository nach dem fehlerhaften Link durchsuchen, um die Datei zu finden.

Wenn Sie den fehlerhaften Link gefunden haben, stellen Sie sicher, dass der Link ordnungsgemäß versioniert ist. Wenn der Artikel beispielsweise nur für GHES Version 3.8+ vorhanden ist, stellen Sie sicher, dass der Link für 3.8+ versioniert ist.

Wenn ein Artikel, der für GitHub Enterprise Server verfügbar ist, auf eine andere Version von GitHub Docs verweist, fügen Sie die Version in den Pfad ein, um zu verhindern, dass die URL automatisch umgewandelt wird und eine GitHub Enterprise Server Versionsnummer enthält. Das folgende Beispiel zeigt, wie man von einem GitHub Enterprise Server-Artikel zu einer Free, Pro, & Team Version eines Artikels gelangt.

[{{ data variables.product.prodname_github_connect }} Addendum to the {{ data variables.product.prodname_enterprise }} License Agreement](/free-pro-team@latest/articles/github-connect-addendum-to-the-github-enterprise-license-agreement/)"

Lokales Debuggen

Während der Entwicklung können Sie jede Seite auf http://localhost:4000 besuchen und am Ende des Pfads ?json=page hinzufügen, um einige zugrunde liegende Informationen anzuzeigen, die beim Debuggen hilfreich sein können. Zusätzlich zu grundlegenden Informationen wie Titel und Einführung sind dies einige Felder, die nützlich sein können.

FeldBeschreibung
productVersionsZeigt an, was die Website vom productVersions-Frontmatter analysiert.
permalinksZeigt alle Permalinks an, die die Website für die Seite generiert.
redirect_fromZeigt die hartcodierten Umleitungen im redirect_from-Frontmatter an.
redirectsZeigt alle Umleitungen an, die die Website für die Seite generiert.
includesPlatformSpecificContentZeigt an, ob die Website plattformspezifische Inhalte auf der Seite erkennt.

Arbeiten mit flüssiger Verarbeitung

Wenn Ihr Text oder Codebeispiel Inhalte in geschweiften Klammern ({ und }) enthält, müssen Sie ihn zwischen &#123% raw %}- und &#123% raw %}-Tags einschließen, um die Liquid-Verarbeitung für diesen Abschnitt zu deaktivieren. Zum Beispiel:

  • Verwendung:

    GITHUB_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}

  • Vermeiden:

    GITHUB_TOKEN: $${{ secrets.GITHUB_TOKEN }}$