Wie ein Projekt funktioniert¶
Die Projektwurzel enthält conf.toml. root_doc beginnt die Lesereihenfolge. Guidedog findet und liest Quelldokumente, löst ihre Beziehungen auf und veröffentlicht eine vollständige Generation.
Dokumente und Ressourcen¶
Die Endung wählt den Reader. RST und Projekt-Markdown teilen den Graphen. Bilder und Downloads sind Ressourcen; verwendete werden kopiert. Theme-Dateien stehen in html_static_path. Includes müssen im Quellverzeichnis oder in include_roots bleiben.
Getrennte Projekte¶
Trennen Sie Handbuch und Designaufzeichnungen: Leser und Lesereihenfolge unterscheiden sich. Jedes Projekt hat eigene Konfiguration, Vorlagen, Cache und Ausgabe. Guidedog nutzt dafür docs/manual und docs/gds.
Inkrementelle Builds¶
Guidedog erfasst Eingaben und Abfragen je Ausgabe. Geänderte Quellen werden neu gelesen, geänderte Abhängigkeiten invalidieren ihre Nutzer. Vorlagenänderungen können alle Seiten betreffen. Unveränderte Dokumente lassen sich aus gespeicherten Objekten laden.
Der Cache ist ein Nachweis des früheren Builds, nicht die maßgebliche Quelle. -E verwirft die gespeicherte Umgebung für den nächsten Build. -a schreibt alle Ausgaben. Sie lösen unterschiedliche Probleme.
Ein expliziter Vorlagenzeitstempel ist ebenfalls Eingabe. Eine Seite mit aktueller Minute kann sich trotz unveränderter Prosa ändern. Nutzen Sie SOURCE_DATE_EPOCH für eine feste Build-Zeit.
Veröffentlichung¶
Änderungen gehen in ein benachbartes Staging-Verzeichnis. Nach Fertigstellung und Flush von Dateien und Aufzeichnungen werden Generationen gewechselt. Leser sehen die vollständige alte oder neue Ausgabe. Unterbrochene Commits klärt der nächste Build. Design und Beweispflichten stehen in Eine vollständige Generation veröffentlichen.