Haha, comme je l’ai dit, je l’utilise pour autre chose, je ne peux pas simplement l’arrêter. Il ne devrait certainement pas être si difficile de changer le port (célèbres dernières paroles, semble-t-il)
1 « J'aime »
Je vous suggère de poser cette question dans le sujet lié. D’après un bref aperçu de ce script, il semble codé en dur, mais je pourrais me tromper, le script pourrait être intégré.
J’ai également remarqué les éléments codés en dur, mais il existe des références à une configuration de port dans les fichiers yml ainsi qu’à des variables d’environnement. Je abandonne pour l’instant. Trop de temps déjà investi pour ce que je voulais tester.
J’ai lancé une VM avec une Ubuntu 22.04 fraîche. L’installation de développement échoue : Install Discourse for development using Docker - #213 by nordize
Ce n’est pas mon jour… mais ce n’est certainement pas en quelques minutes non plus (sans jeu de mots). Merci pour votre temps, et désolé de vous avoir fait perdre le vôtre aussi.
1 « J'aime »
@merefield question rapide : existe-t-il un moyen plus rapide d’obtenir les mises à jour du code des plugins dans le conteneur que de faire d/shutdown_dev; d/boot_dev, ce qui prend une éternité et télécharge une tonne de données car il récupère les images Docker ? Le faire à chaque fois que je change une ligne de code pour tester dans le navigateur semble totalement excessif, même pour un environnement Dockerisé.
Redémarrer le serveur Rails avec d/rails s ne voit pas les changements de code de mon plugin.
Ceci ne devrait être nécessaire que si vous supprimez ou ajoutez un plugin, pas si vous modifiez une ligne de code.
S’il s’agit de Ruby ou de CSS, le nouveau code sera chargé à chaud. S’il s’agit de Ruby, vous devriez voir les licornes redémarrer dans le terminal, si je me souviens bien.
S’il s’agit de JavaScript, il vous suffit de rafraîchir le navigateur.
J’aurais dû mentionner que mon plugin est dans un lien symbolique, et que tout changement n’est pas reflété à moins que vous ne fassiez d/shutdown_dev; d/boot_dev (ceci est également mentionné dans le guide), mais j’espérais qu’il y aurait une solution de contournement via Docker lui-même puisque ce ne devraient être que des fichiers mappés. Je vais peut-être demander dans l’autre fil de discussion ou voir si je peux le modifier comme solution de contournement (ou ne pas utiliser de liens symboliques).
Cela ne me semble pas correct. Le processus du serveur redémarre simplement comme il le fait dans une installation non-docker. Les liens symboliques ne devraient faire aucune différence et constituent la manière appropriée de travailler. Je n’ai aucune idée pourquoi le vôtre ne se comporte pas ainsi…
Eh bien, n’hésitez pas à l’essayer. Je ne l’aurais pas publié si redémarrer rails et ember avait suffi. Comme je disais, le guide le souligne également.
Selon le guide, l’exécution de ces commandes de redémarrage ne devrait être nécessaire que si vous modifiez la population des plugins (par exemple, en supprimant ou en ajoutant un lien symbolique valide). Sinon, Rails devrait détecter les modifications de code et redémarrer ses processus. Il pourrait être possible de désactiver ce comportement dans la configuration, mais ce devrait être le comportement par défaut.
Voici un exemple de redémarrage automatisé, bien que sur une installation de développement non Docker, mais le comportement devrait être similaire :
[DEV] : Fichiers modifiés qui ne sont pas automatiquement chargés. Redémarrage du serveur...
- plugins/discourse-multilingual/extensions/post.rb
REDÉMARRAGE DE UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : reaped #<Process::Status: pid 228047 exit 0> worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : reaped #<Process::Status: pid 228048 exit 0> worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : reaped #<Process::Status: pid 228049 exit 0> worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : master complete
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : Refreshing Gem list
Got TERM signal
Shutting down
Terminating quiet threads
Scheduler exiting...
Pausing to allow jobs to finish...
Bye!
Starting CSS change watcher
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : listening on addr=0.0.0.0:3000 fd=25
J’ai modifié le fichier post.rb et enregistré, le reste est automatisé.
Désolé, je n’ai pas accès à ma machine de développement basée sur Docker où je me trouve actuellement pour confirmer que c’est bien le cas sur l’installation Docker également, mais je me souviens que c’est le cas, à moins que quelque chose n’ait changé.
Je n’invente rien, vous savez 
et je ne peux pas faire grand-chose quand on me dit que ça devrait fonctionner J’ai suivi ce guide à la lettre sur une nouvelle installation de VM avec Ubuntu 22.04.
- Lier le plugin dans le sous-dossier discourse/plugins/ et modifier le code JS dans le plugin n’est pas vu à moins que je ne fasse d/shutdown_dev; d/boot_dev, malgré le redémarrage de d/rails s et d/ember-cli
- Copier le plugin dans le sous-dossier discourse/plugins/ et modifier le code JS dans le plugin est vu sans faire d/shutdown_dev; d/boot_dev mais seulement en redémarrant d/rails s et d/ember-cli
N’hésitez pas à essayer ce qui précède. Le plugin en question est discourse-math, en modifiant le code dans assets/initializers/javascript/*.js (gardez à l’esprit que ces fichiers de plugin particuliers sont chargés séparément et ne sont pas appelés directement par le navigateur ; je ne suis pas sûr si cela fait une différence, je n’ai pas encore creusé trop profondément dans le fonctionnement interne de Discourse).
p.s. Je sais que je dois rafraîchir le navigateur (en contournant le cache)… faites-moi un peu confiance.
Directement de la source :
Le problème est donc potentiellement localisé chez vous, ou une régression dans la version actuelle, mais cette dernière option semble peu probable.
J’abandonne, tu as gagné. Si jamais tu l’essaies toi-même, fais-le moi savoir.
Je n’essaie certainement pas de « gagner », mais nous devons parvenir à une compréhension de base :
- il est censé redémarrer automatiquement lors des modifications du code backend.
d/shutdown_dev; d/boot_devne devrait être nécessaire que lorsque vous modifiez la population des plugins, pas seulement des lignes de code individuelles.
Cela devrait réduire l’endroit où vous devez chercher pour corriger les choses.
Je viens de faire un git pull et d’essayer un changement, il redémarre, donc ce n’est pas une régression de build.
Le plus étrange pour moi est qu’étant une configuration docker, il est en fait plus difficile de remplacer involontairement le comportement empaqueté, donc il devrait être plus fiable.
J’essaierai cela sur ma build docker quand je rentrerai à la maison.
J’apprécie que ce soit frustrant et ennuyeux comme flux de travail actuellement, cela m’ennuierait et me frustrerait certainement.
Si vous avez complètement vidé votre cache, je ne suis pas sûr de quoi suggérer à ce stade.
Notez que les initializers ne s’exécutent qu’une seule fois lorsque vous ouvrez la page pour la première fois. Ainsi, le redémarrage des processus du serveur est discutable (et ne couvre que le code backend).
Je désactive la mise en cache lorsque j’utilise les outils de développement pour développer des applications web. Je débute seulement avec le code et les outils de Discourse, pas avec le développement (web). J’ai également posté une question dans le fil de discussion du guide. Pour l’instant, j’ai juste copié le répertoire du plugin sous discourse/plugins/ pour éviter les désagréments.
1 « J'aime »
J’essaierai quelque chose de similaire plus tard aujourd’hui et je ferai un compte rendu.
D’après ce que je peux voir des appels du navigateur, le code JS de l’initialiseur JS est chargé de manière asynchrone via discourse-math.js, via eval() (à chaque ouverture de page), ce qui suggère clairement qu’un composant côté serveur traite et met en cache ce code JS de l’initialiseur (celui que je modifie), et donc c’est ce cache côté serveur particulier qui doit être déclenché pour le remettre en cache… ce qui n’arrive pas si le plugin est lié symboliquement mais arrive lorsqu’il est copié.
Je ne suis pas familier (et je ne voulais pas me familiariser à ce moment-là par manque de temps) avec la chaîne d’outils Discourse… d’où mon rétro-ingénierie et mes questions.
1 « J'aime »
non-docker dev :
J’ai essayé cela tout à l’heure sur un initialiseur, aucun redémarrage de processus nécessaire, juste un rafraîchissement du navigateur a capté le changement dans le code js… c’était non-docker… J’essaierai ça plus tard
un peu plus tard…
docker-dev :
OK, je suis maintenant sur mon PC et j’ai essayé la solution docker pour laquelle j’ai fait une installation entièrement neuve, et je vois le même comportement : les modifications de l’initialiseur fonctionnent pour moi en laissant les serveurs tourner et en sauvegardant simplement le fichier et en rafraîchissant le navigateur, aucune reconstruction du conteneur n’est nécessaire.
Donc, même comportement
(J’ai utilisé le plugin Discourse Locations comme exemple.)
Êtes-vous sûr que rien ne cloche avec votre initialiseur ?
Étant donné que cela fonctionne après le redémarrage, oui, j’en suis sûr. Pour une reproductibilité fiable à 100 %, vous pourriez essayer le plugin spécifique que j’ai mentionné, l’activer dans l’interface graphique et choisir l’option Katex dans l’interface graphique, puis modifier le fichier JS d’initialisation que j’ai mentionné, puis faire un post avec du code Latex à l’intérieur ; ce plugin pourrait être spécial, chargeant potentiellement son initialiseur JS à la volée uniquement si le post contient du code Latex (c’est ce que je ferais si je concevais Discourse)… mais je ne m’attends pas à ce que vous perdiez du temps sur ce problème, et je n’essaie pas non plus de vous persuader que je n’invente pas
1 « J'aime »
C’est un bon point.
C’est très, très étrange.
Ma seule suggestion pour le moment est de passer à une installation non-docker (qui prend malheureusement plus de temps à configurer 
) et de voir comment cela se passe ?
Il serait bon d’avoir l’avis de l’équipe sur ce qui pourrait mal se passer pour vous. Cependant, la solution docker réduirait sûrement les chances d’un comportement différent ici car elle est conteneurisée et atomique 