Ich habe ein Skript geschrieben, das von einer YAML-Datei gesteuert wird, um eine Discourse-Site neu anzuordnen. Dies liegt daran, dass ich eine ziemlich massive Neuanordnung meiner größten Website plane, um die Navigation zu erleichtern, und ich werde es niemals durchziehen, wenn ich versuche, es über die Benutzeroberfläche zu steuern.
Mein Skript hat null Unit-Tests, und obwohl ich ein allgemeiner Befürworter von Unit-Tests bin und das schon seit langem bin, bin ich nicht motiviert, welche für dieses Skript zu schreiben.
Das Skript ist eigentlich ein Framework, auf dem man aufbauen kann – nicht jeder wird die gleichen Semantiken wollen, die ich will. In diesem Sinne ist es eher wie einige der Migrationsskripte, bei denen man erwartet, dass die Leute sie wahrscheinlich modifizieren, um sie anzupassen.
Sind diese Einschränkungen etwas, das eine PR wert ist? Oder würden die Leute es vorziehen, wenn ich es als Codeblock poste, vielleicht in #documentation:sysadmin?
Ich möchte vor allem anderen helfen, die etwas Ähnliches versuchen. Außerdem könnten die tatsächlichen Funktionen den Leuten helfen zu wissen, was sie in der Rails-Konsole tun sollen.
Ich verstehe „MSN“ nicht, aber in meinem Fall beinhaltet das, was ich tue, das Verschieben von Beiträgen zwischen Kategorien, das Hinzufügen von Tags, das Ändern der Eltern von Beiträgen, das Ausblenden von Kategorien, das Hinzufügen von Weiterleitungen … Einige der Aufgaben sind in „Administrative Bulk Actions“ abgedeckt und einige nicht, aber in jedem Fall alle von einem einzigen Skript aus.
Derzeit sind das in meinem Fall 112 Aktionen. Ich tippe das nicht in einer Kombination aus rails c und rake hin und her, möglicherweise mehrmals pro Stunde, während ich verschiedene Neuorganisationen meiner Website mit meiner Website-Leitung erkunde.
Die Frage ist nicht: „Wie kann ich das erreichen?“ – Ich habe es bereits geschrieben, obwohl ich beabsichtige, es weiter zu verbessern (z. B. werde ich es wahrscheinlich auch ein vollständiges, detailliertes Audit-Protokoll schreiben lassen, etwas, das es noch nicht tut, aber ich möchte es vielleicht haben, bevor ich es tatsächlich für die Live-Website ausführe).
Die Frage ist: Wie teile ich es am besten? Ich sehe nichts Vergleichbares im Verzeichnis scripts/ (obwohl ich vielleicht etwas übersehen habe) und ich schätze, dass PRs normalerweise mit automatisierten Tests geliefert werden sollten (obwohl ich nicht weiß, wie stark dies für das Verzeichnis scripts/ gilt). Gleichzeitig ist es bereits über 150 Zeilen lang und wächst, was für die Weitergabe durch Posten hier zu groß erscheint, wo es erheblich größer wäre als eine Codebox.
Die Erstellung als eigenständiges GitHub-Projekt ist der beste Weg. Stellen Sie außerdem sicher, dass Sie hier auf Meta ein Thema über das Tool erstellen, damit die Leute davon erfahren.
Ja, ich möchte auf jeden Fall, dass die Leute es finden können!
Ich habe es mit:
require_relative "../config/environment"
begonnen, damit es funktioniert, wenn es im Skriptverzeichnis platziert wird. Gibt es ein gängiges Muster, um es außerhalb des Discourse-Verzeichnisses zu belassen? (Ich sehe nichts in .gitignore, das dem Muster für Plugins ähnelt, um Dinge außerhalb von Plugins auszuchecken.)
Wenn nicht, kann ich einfach „in Skripte kopieren“ als Installationsanleitung angeben, aber ich möchte nur wissen, ob es etwas gibt, das ich tun kann, um besser hineinzupassen.
