Libelektra: Eine Website erstellen

• Dokumentation korrigiert, damit sie auf der Website gut aussieht und einen einheitlichen Stil hat
• News/Changelog-Seite
• gleiche Stabilität auch für das Backend
• todos in #1030 fertig

Ich denke, die Registrierungsstabilität ist kein Problem. Dies liegt in unserer Verantwortung, die Datenbank nicht zu löschen.

Danke für deinen Beitrag!

Ich habe Ihre Punkte hinzugefügt, außer dass dort "Dokumentation _meistens_ behoben" steht und ich ausgeschlossen habe, dass #1030 vollständig durchgeführt werden muss. Wäre natürlich schön, es zu haben, aber es ist nicht unbedingt erforderlich. Stattdessen fügte ich hinzu: "Einstiegspunkte der Doku sind schön und Korrektur gelesen".

Ich habe Bereitstellungspipeline und Sicherheit hinzugefügt

Die Bereitstellung über Build sollte eigentlich schon funktionieren.

Dankeschön! Bereitstellung funktioniert! Aber bitte beseitigen Sie die Schlaf(s) während der Bereitstellung. Dies fügt eine Menge Ausfallzeiten hinzu.

Ich habe den Schlaf zwischen dem Backend-Stopp und dem Start entfernt, aber der andere Schlaf sollte aus gutem Grund bleiben:
Das Startskript führt das Backend im Hintergrund aus und da der Cache zuerst geladen werden muss, können wir nicht sicher sein, ob das Backend bereits erreichbar ist (notwendig für die Sitemap-Generierung und wird diesmal mit der Anzahl der Snippets zunehmen). Die 60 Sekunden Schlaf sind aber kein Problem, da die letzte Frontend-Version noch immer online und erreichbar ist - wir überschreiben einfach die Frontend-Dateien, ohne sie zu löschen.

Perfekt, ist dann gelöst!

Ich habe auch "Versionshinweise für den neuen Snippet-Dienst/die neue Webseite schreiben" hinzugefügt. Es sollte nichts Neues sein und ich kann helfen. Können wir auch das Homebrew und andere Dinge erwähnen (die nicht direkt mit der Software zusammenhängen)?

Übrigens. Wie erstellt man am einfachsten Vorabnachrichten, die noch nicht auf der Website angezeigt werden sollen?

Eine PR oder eine neue Filiale sollte der einfachste Weg sein, um eine vorzeitige Veröffentlichung zu vermeiden.

Was ist, wenn Sie nicht die richtige Dateierweiterung haben? Oder verwenden Sie jede Datei aus dem News-Verzeichnis?

Das News-Skript schlägt bei unangemessenen Dateinamen fehl, aber dies könnte leicht geändert werden, sodass es ignoriert wird.

Ja, es wäre schön, eine Möglichkeit zur Nachrichtenvorbereitung zu haben, ohne dass zusätzliche Zweige oder ähnliches erforderlich sind. Wie wäre es mit einer expliziten Synax dafür? (Vielleicht beginnend mit _ oder so?) Dann können Sie bei fehlerhaften Einträgen immer noch scheitern.

Es schlägt absichtlich bei Dateinamen fehl, die nicht mit einer bestimmten Regex übereinstimmen, aber ich kann es in eine Warnung ändern, damit das Skript durchläuft. Dann können Sie alles verwenden, was nicht mit der Regex übereinstimmt, zB einen Unterstrich als Präfix. Ich werde dies bei der Vorbereitung der Nachrichten tun.

Ich meine, wir sollten nur eine ganz bestimmte Konvention für die Nachrichtenvorbereitung zulassen. Es ist nützlich, andernfalls bei falschen Namen zu scheitern.

Übrigens. Haben Sie überprüft: Schlägt die Installation (und der Homepage-Build) fehl, wenn npm fehlschlägt?

Ich meine, wir sollten nur eine ganz bestimmte Konvention für die Nachrichtenvorbereitung zulassen. Es ist nützlich, andernfalls bei falschen Namen zu scheitern.

Nein, eigentlich reicht eine Warnung, denn es gibt nicht wirklich ein Problem mit falschen Dateinamen. Wir könnten dort zum Beispiel auch eine CMakeLists.txt haben. Nicht verwandte Dateien bedeuten nicht direkt, dass etwas defekt ist.

Übrigens. Haben Sie überprüft: Schlägt die Installation (und der Homepage-Build) fehl, wenn npm fehlschlägt?

Das Erstellen der Homepage schlägt eindeutig fehl (kein Grunzen oder keine Abhängigkeiten = keine Homepage), aber wenn die cmake-Installation fehlschlägt ... keine Ahnung. Du hattest aus erster Hand Probleme mit npm, also solltest du es besser wissen?

Wir könnten dort zum Beispiel auch eine CMakeLists.txt haben.

Warum sollten wir das tun? Und wenn wir dort eine Datei hinzufügen (sagen wir README.md) möchte ich sicherlich nicht jedes Mal eine Warnung haben ;)

Nicht verwandte Dateien bedeuten nicht direkt, dass etwas defekt ist.

Tatsächlich ist es in diesem Fall höchstwahrscheinlich der Fall: Es könnte sich um einen Tippfehler handeln. Aber eine Warnung sollte auch in Ordnung sein. (Es ist offensichtlich, wenn eine Nachricht fehlt.) Aber im Allgemeinen ist es besser, wenn der Aufbau der Homepage im Fehlerfall fehlschlägt. (Dann bekomme ich eine Mail, dass die Homepage von Jenkins nicht gebaut werden konnte)

Übrigens. Ist jenkins in der Lage, die von npm ausgegebenen Warnungen zu sammeln?

aber wenn die cmake-Installation fehlschlägt... keine Ahnung.

Könnten Sie es bitte versuchen? Erstellen Sie einfach eine PR, die unbedingt zu einem Fehler führt und starten Sie den HP-Build mit der Phrase.

Du hattest aus erster Hand Probleme mit npm, also solltest du es besser wissen?

Die cmake-Installation ging weiter, aber ich habe nicht nachgesehen, wie der gesamte Exit-Status war.

Warum sollten wir das tun? Und wenn wir dort eine Datei hinzufügen (sagen wir README.md) möchte ich sicherlich nicht jedes Mal eine Warnung haben ;)

Aber Sie schlagen vor, eine Fehlermeldung statt einer Warnung zu erhalten ... das macht keinen Sinn. :Lächeln:

Könnten Sie es bitte versuchen? Erstellen Sie einfach eine PR, die unbedingt zu einem Fehler führt und starten Sie den HP-Build mit der Phrase.

Was ist Ihre gewünschte Ausgabe? Dass cmake bei einem npm-fail fehlschlägt? Ich meine, es wird eindeutig eine Fehlermeldung geben, die das Problem angibt, z

npm executable was not found
npm package <xyz> not in the npm registry
...

Daher bezweifle ich, dass es überhaupt ein Problem ist.

Aber Sie schlagen vor, eine Fehlermeldung statt einer Warnung zu erhalten ... das macht keinen Sinn. :Lächeln:

Ja, ein Fehler sollte alles abbrechen und dann fügen wir explizite Unterstützung für solche Dateien hinzu (falls jemals benötigt).

Was ist Ihre gewünschte Ausgabe? Dass cmake bei einem npm-fail fehlschlägt? Ich meine, es wird eindeutig eine Fehlermeldung geben, die das Problem angibt, z

Der Build-Job sollte abgebrochen werden, bevor er die Homepage beschädigt.

Vielleicht gibt es sowieso kein Problem.

Hm, Grunzen-Aufgaben scheitern zu lassen, ist ein Problem; es kann möglicherweise die Homepage beschädigen. Das sollten wir also wohl vermeiden.

Vielleicht wäre es besser, die Aufgabe während der Kompilierungsphase auszuführen (dann wäre ein Scheitern kein Problem) und während der Installationsphase würden wir nur Dateien kopieren?

Auch wenn Sie dies nicht tun können, weil die Änderungen zu groß sind, sollten wir dies zumindest für die @omnidan- Web-GUI richtig

Es ist eine kleine Änderung in der package.json des Rest-Frontends und kein Problem; aber ich kann es nicht nur für unseren Homepage-Build-Job tun - es wäre für alle Installationen.

Aber ich sehe den Vorteil nicht, um ehrlich zu sein, denn wenn Sie das Frontend-Build-Skript starten, löscht es den Website-Inhalt und erstellt ihn Schritt für Schritt durch verschiedene Skripte neu. Und da das Skript für cmake und das Build-Skript identisch ist, würde es beide Male fehlschlagen.

Es ist eine kleine Änderung in der package.json des Rest-Frontends und kein Problem; aber ich kann es nicht nur für unseren Homepage-Build-Job tun - es wäre für alle Installationen.

Natürlich.

Aber ich sehe den Vorteil nicht, um ehrlich zu sein

Vielleicht reden wir aneinander vorbei, also ist die Idee:

make # kompiliert/baut auch das Frontend, kann fehlschlagen
make install # kopiert nur Dateien, schlägt nur bei Zugriffsberechtigungen/Disk voll fehl

Der Vorteil ist, dass wir, wenn wir translations/en.json, resources/structure.json.in oder andere wichtige Dinge irgendwie korrumpieren, wir

1. haben make fehlgeschlagen (macht frühzeitig klar, dass hier etwas nicht stimmt)
2. den Build-Job fehlschlagen lassen (wegen 1.)
3. keine Teilinstallationen haben (die Installation würde nie starten, wenn make nicht erfolgreich bestanden wird)

denn wenn Sie das Frontend-Build-Skript starten, löscht es den Website-Inhalt und erstellt ihn Schritt für Schritt durch verschiedene Skripte neu. Und da das Skript für cmake und das Build-Skript identisch ist, würde es beide Male fehlschlagen.

Vielleicht habe ich ein falsches Verständnis, aber für mich hat make install gereicht, um die neue Website zu erhalten, ich führe das Frontend-Build-Skript nicht erneut aus. In welchen Situationen muss ich das Frontend-Build-Skript erneut ausführen?

Vielleicht sollte das Frontend-Skript nicht den Website-Inhalt löschen, sondern ein temporäres Verzeichnis erstellen und dann das erfolgreich erstellte öffentliche Verzeichnis an sein Ziel verschieben?

Vielleicht reden wir aneinander vorbei, also ist die Idee:

Jetzt hab ich es verstanden. Wenn es eine Möglichkeit gibt, die Homepage im Binärverzeichnis zu erstellen, könnte dies funktionieren. Ich bin mir nicht 100% sicher über die Pfade, die konfiguriert sind, muss es mir ansehen.

In welchen Situationen muss ich das Frontend-Build-Skript erneut ausführen?

Die cmake-Installation führt grunt install , während das Build-Skript grunt full ausführt. Der einzige Unterschied besteht darin, dass grunt full auch eine Sitemap erstellt, was erfordert, dass das Rest-Backend aktiv ist (damit die Snippets aufgelistet werden können).

Vielleicht sollte das Frontend-Skript nicht den Website-Inhalt löschen, sondern ein temporäres Verzeichnis erstellen und dann das erfolgreich erstellte öffentliche Verzeichnis an sein Ziel verschieben?

Auch eine Idee, aber ich bin mir noch nicht sicher, ob sich der Aufwand lohnt. Wir konnten einfach nicht zulassen, dass das Grunzen-Kommando versagte; dann haben wir immer eine funktionierende Website (wenn nicht jemand die Berechtigungen ändert oder etwas anderes passiert, das nicht die Schuld des Skripts ist).

erstellt auch eine Sitemap, die erfordert, dass das Rest-Backend aktiv ist

Ahh ok. Wäre es dann nicht schöner, wenn das Skript genau die Sitemap produziert und sonst nichts? Vielleicht können wir das sogar als Cron-Job ausführen?

Wir konnten einfach nicht zulassen, dass das Grunzen-Kommando versagte; dann haben wir immer eine funktionierende Website

Ja, immer eine funktionierende Website zu haben ist hier das mit Abstand wichtigste Thema!

Ahh ok. Wäre es dann nicht schöner, wenn das Skript genau die Sitemap produziert und sonst nichts? Vielleicht können wir das sogar als Cron-Job ausführen?

Sie können jede Aufgabe auch separat ausführen, grunt full (was eigentlich grunt default oder nur grunt ) und grunt install sind nur eine Liste von Aufgaben, die nacheinander ausgeführt werden . Also ja, ein Cronjob für die Sitemap wäre sinnvoll (wir müssen aber aufpassen, dass die Datei nicht mit den falschen Rechten/Benutzern geschrieben wird, sonst können andere Installationen fehlschlagen).

Da der gesamte Front-End-Build jedoch nur wenige Sekunden dauert, glaube ich nicht, dass das Entfernen des Build-Skripts aus dem Build-Job große Auswirkungen hat.

@e1528532 Können Sie einen Blick darauf werfen, ob die Haupteinstiegspunkte der Website gut sind (und Korrekturen bereitstellen, wenn dies nicht der

Danke, tolle Seite! Jetzt brauchen wir mehr Schnipsel ;)

Dies ist das erste gelöste 1.0.0-Problem! :Feuerwerk: