J’écris un script, piloté par un fichier YAML, pour réorganiser un site Discourse. C’est parce que je prévois une réorganisation assez massive de mon plus grand site pour le rendre plus facile à naviguer, et je ne le ferai jamais si j’essaie de le faire via l’interface utilisateur.
Mon script n’a aucun test unitaire, et bien que je sois un partisan général des tests unitaires depuis longtemps, je ne suis pas motivé à en écrire pour ce script.
Le script est vraiment un cadre sur lequel construire — tout le monde ne voudra pas les mêmes sémantiques que moi. En ce sens, c’est un peu comme certains scripts de migration où l’on s’attend à ce que les gens les modifient probablement pour les adapter.
Avec ces contraintes, est-ce quelque chose qui vaut la peine de soumettre une PR ? Ou préféreriez-vous que je le publie sous forme de bloc de code, peut-être dans #documentation:sysadmin ?
Je veux surtout aider toute autre personne qui essaie de faire quelque chose de similaire. De plus, les fonctions réelles pourraient aider les gens à savoir quoi faire dans la console Rails.
Je ne comprends pas « MSN », mais dans mon cas, ce que je fais inclut le déplacement de publications entre catégories, l’ajout de balises, la modification de la hiérarchie des publications, la masquage de catégories, l’ajout de redirections… Certaines des tâches sont couvertes par les actions de masse administratives et d’autres non, mais dans tous les cas, toutes proviennent d’un seul script.
Actuellement, dans mon cas, cela représente 112 actions. Je ne vais pas taper cela dans une combinaison de rails c et rake aller-retour, potentiellement plusieurs fois par heure alors que j’explore différentes réorganisations de mon site avec ma direction.
La question n’est pas « comment puis-je accomplir cela ? » — Je l’ai déjà écrit, bien que j’aie l’intention de continuer à l’améliorer (par exemple, je vais probablement aussi lui faire écrire un journal d’audit complet et détaillé, ce qu’il ne fait pas encore mais que je pourrais vouloir avoir avant de l’exécuter réellement pour le site en direct).
La question est : comment le partager au mieux ? Je ne vois rien de tel dans le répertoire scripts/ (bien que j’aie peut-être manqué quelque chose) et j’apprécie que les PR soient normalement accompagnés de tests automatisés (bien que je ne sache pas à quel point cela s’applique au répertoire scripts/). En même temps, il fait déjà plus de 150 lignes et il grandit, ce qui semble beaucoup pour le partager en le postant ici, où il serait beaucoup plus grand qu’une boîte de code.
Je pense que vous le publiez sur github et que vous y mettez un lien - soit vous créez un sujet pour cela, soit vous l’ajoutez aux opérations groupées d’administration.
La meilleure façon de procéder est de le créer en tant que projet GitHub autonome. Assurez-vous également de créer un sujet à propos de l’outil ici sur Meta afin que les gens puissent en prendre connaissance.
Oui, je veux absolument que les gens puissent le trouver !
J’ai commencé avec :
require_relative "../config/environment"
pour que cela fonctionne lorsqu’il est placé dans le répertoire scripts. Existe-t-il un modèle courant pour le faire vivre en dehors du répertoire discourse ? (Je ne vois rien dans .gitignore comme le modèle de plugins pour extraire des éléments autres que des plugins à l’intérieur d’une extraction.)
Sinon, je peux simplement dire « copiez-le dans scripts/ » comme instructions d’installation, mais je veux juste savoir s’il y a quelque chose que je peux faire pour mieux m’intégrer.
