J’ai une installation Docker standard (edit : non-dev) dans /var/discourse. Est-il possible d’utiliser un répertoire de plugin local pour charger Discourse au lieu de lier à un dépôt GitHub distant depuis app.yml ? Si oui, comment ?
J’ai essayé deux méthodes qui auraient dû fonctionner :
J’ai cloné discourse-math depuis GitHub dans /var/discourse/plugins/discourse-math. launcher rebuild n’a rien dit à propos de discourse-math et il n’y a pas de discourse-math dans le montage Docker non plus, ni dans l’interface graphique. Je suppose donc que le dossier plugins est ignoré ?
J’ai également essayé de cloner dans un répertoire différent en dehors de /var/discourse et de le lier symboliquement à /var/discourse/plugins/discourse-math… même résultat.
J’ai cloné le dépôt GitHub dans /var/discourse-math.git et j’ai modifié mon app.yml pour dire - git clone file:////var/discourse-math.git mais ensuite launcher rebuild s’est plaint fatal: '/var/discourse-math.git' does not appear to be a git repository… le lanceur exécute cela dans un conteneur Docker déjà ? Exécuter manuellement cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git fonctionne très bien.
Le répertoire plugins se trouve en dehors du conteneur Docker et est monté.
Donc, si vous exécutez votre conteneur Docker Discourse depuis ~/discourse, vous pouvez cloner vos plugins ou créer un lien symbolique vers ~discourse/plugins localement.
Oui, j’étais au courant de l’installation pour développeurs, mais j’ai une installation Docker standard (c’est-à-dire une installation non pour développeurs), donc je suppose que ma question reste valable : puis-je charger un plugin à partir d’un répertoire local ou uniquement à distance depuis GitHub via app.yml ?
p.s. Je suis bien conscient que le flux « correct » est d’avoir une installation pour développeurs et d’y jouer. Je voulais un moyen rapide et sale de modifier et de tester un plugin au lieu de passer par toute la douleur d’une installation et d’une configuration pour développeurs.
L’installation de production clonera les plugins dans le conteneur, ce qui n’est donc pas adapté au développement de plugins locaux, car pour ce flux de travail, vous devrez télécharger vos modifications sur GitHub.
Ma suggestion est de jeter cette configuration et d’utiliser l’une des deux options de développement majeures, Docker ou non-Docker.
Pour m’assurer que je vous ai bien compris : vous faites référence au clonage de plugins github distants, et non à la possibilité de cloner à partir d’un répertoire local, même via github file:///. Je suppose que launcher.sh s’exécute à ce stade dans un conteneur et non sur l’hôte, c’est-à-dire qu’il clone depuis github pendant qu’il est dans le conteneur, au lieu de cloner depuis l’hôte dans le dossier monté de l’hôte… ce qui me permettrait de faire un git clone file:///…
Si vous souhaitez transformer l’installation de production en un assemblage hétéroclite capable d’accéder aux répertoires montés localement, vous devrez modifier les scripts de build pour lui accorder cet accès. Vous devrez alors assumer vous-même la prise en charge de ces personnalisations.
À mon humble avis, vous ne faites que vous créer du travail et de la fragilité.
L’installation Docker pour le développement est précisément conçue pour vous offrir une solution à faible maintenance pour le développement efficace de plugins locaux, veuillez envisager de l’utiliser.
Je sais, et vous avez raison, bien sûr. C’était pour un simple changement à tester dans un fichier javascript d’un plugin. Je l’ai modifié directement dans le conteneur (/var/www/discourse/public/assets/plugins/discourse-math-.js) mais pour une raison quelconque, mes modifications ne sont pas reflétées dans le navigateur - le navigateur voit l’ancien fichier, malgré le nettoyage du cache, probablement parce que les fichiers js du plugin sont mis en cache par le nginx embarqué ou quelque chose comme ça (?).
Je serais reconnaissant pour un conseil sur la façon de modifier un fichier js actuel dans le conteneur (aussi ridicule que cela puisse paraître) et de le rendre visible par le navigateur.
J’ai peut-être déjà fini dans le territoire du « Je n’ai pas eu le temps d’écrire une courte lettre »… Je n’ai pas eu le temps de suivre la bonne voie d’une installation de développement et je ne m’attendais pas à ce que ce soit si difficile de modifier un fichier js à l’intérieur du conteneur (peu de temps pour lire comment Discourse met en cache les fichiers js des plugins pour rendre mes changements visibles dans le navigateur), etc. etc.
C’est un fichier js d’un plugin existant (à savoir l’initialiseur) que je veux modifier. Les composants de thème ne m’aident pas (sauf si je vous comprends mal)
Les composants de thème sont chargés en dernier, je crois, ils remplaceront donc le plugin.
Une autre bonne option consiste simplement à forker le plugin, à le cloner localement pour le modifier et le tester à l’aide d’une installation dev locale (;)). Une fois satisfait, commitez et poussez-le vers votre fork et utilisez le fork pour la production.
Cependant, la solution des composants de thème a l’avantage de ne pas avoir à maintenir un fork qui pourrait devenir une corvée à mesure que le plugin parent évolue.
Je ne suis pas sûr qu’un composant Thème aide lorsque j’ai besoin de modifier un fichier comme celui-ci … ce fichier (ainsi que d’autres), si je comprends bien, passe par le mapper, etc., pour produire le fichier /var/www/discourse/public/applets/plugins/discourse-math-\\u003cid\\u003e.js du conteneur que le navigateur charge. Je n’ai besoin de changer que ce dernier, mais le navigateur voit toujours l’ancien fichier, comme s’il y avait un cache côté serveur.
L’installation de développement local prend du temps et est fastidieuse, mais je pourrais le faire si tout le reste échoue. Je ne m’attendais pas à ce qu’une modification “sale” d’un plugin js soit si douloureuse. Je ne comprends toujours pas pourquoi mes modifications directes ne sont pas visibles dans le navigateur, à moins qu’il y ait un cache côté serveur dans le nginx du conteneur (aucune idée pourquoi étant donné que c’est un js)
Quoi qu’il en soit, le temps que j’avais pour examiner cela aujourd’hui est écoulé :(. Merci pour votre aide de toute façon !
Je ne peux pas entrer dans les détails de ce que vous essayez d’accomplir, mais pour vous assurer qu’un initialiseur s’exécute après un autre, utilisez ce paramètre after:, exemple :
Les outils de développement ont évolué dans ce but précis, alors si vous le pouvez, utilisez-les. La configuration de l’environnement Docker de développement devrait prendre quelques minutes, pas quelques heures, et vous ne devriez avoir à le faire qu’une seule fois, puis il sera utile à toutes sortes de fins par la suite. Ne soyez pas tenté d’utiliser l’installation de production localement uniquement parce que vous la connaissez bien ! Elle n’est tout simplement pas configurée à cet effet.
Appelez-moi stupide, mais comment puis-je changer le port par défaut 3000 pour autre chose ? d/boot-dev --init échoue car j’utilise ce port pour autre chose. J’ai essayé -e UNICORN_PORT=4200. Les guides que j’ai vus ne disent rien sur le port. Le fichier thin.yml dans config/cloud/cloud66/files semble également être ignoré.
3000 est le port du serveur Ruby et 4200 est le port Ember. Les deux processus doivent être en cours d’exécution. Vous accédez au site dans le navigateur via 4200. Mieux vaut discuter de l’installation Docker de développement dans le sujet Docker de développement ?
Eh bien, d/boot_dev --init échoue (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Je creuserai peut-être ça plus tard. Merci pour votre temps. J’aimerais que ces choses soient mieux documentées.
Elle n’est tout simplement pas configurée à cet effet.