Tengo una instalación estándar (editar: no de desarrollo) de Docker en /var/discourse. ¿Es posible usar un directorio de plugins local para cargar en Discourse en lugar de enlazar a un repositorio remoto de GitHub desde app.yml? Si es así, ¿cómo?
Intenté dos métodos que pensé que deberían funcionar:
Cloné discourse-math desde GitHub en /var/discourse/plugins/discourse-math. launcher rebuild no dijo nada sobre discourse-math y tampoco hay discourse-math en el montaje de Docker, ni en la GUI. ¿Así que supongo que la carpeta plugins se ignora?
También intenté clonar en un directorio diferente fuera de /var/discourse y enlazarlo simbólicamente a /var/discourse/plugins/discourse-math… mismo resultado.
Cloné el repositorio de GitHub en /var/discourse-math.git y edité mi app.yml para decir - git clone file:////var/discourse-math.git, pero luego launcher rebuild se quejó fatal: '/var/discourse-math.git' does not appear to be a git repository… ¿supuestamente el lanzador ejecuta esto en un contenedor Docker ya? Ejecutar manualmente cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git funciona perfectamente.
El directorio plugins está fuera del contenedor de Docker y se monta.
Por lo tanto, si está ejecutando su contenedor Docker de Discourse desde dentro de ~/discourse, puede clonar sus plugins o crear un enlace simbólico en ~discourse/plugins localmente.
Sí, sí, era consciente de la instalación de desarrollo, pero tengo una instalación estándar de Docker (es decir, no de desarrollo), así que supongo que mi pregunta sigue en pie: ¿puedo cargar un plugin desde un directorio local o solo de forma remota desde GitHub a través de app.yml?
p.d. Soy muy consciente de que el flujo “correcto” es tener una instalación de desarrollo y jugar allí. Quería una forma rápida y sucia de modificar y probar un plugin en lugar de pasar por todo el dolor de una instalación y configuración de desarrollo.
Entendido, tu configuración inusual me desconcertó.
La instalación de producción clonará los plugins dentro del contenedor, por lo que esto no es adecuado para el desarrollo de plugins local, ya que para ese flujo de trabajo necesitarás subir tus cambios a GitHub.
Mi sugerencia es desechar esa configuración y usar una de las dos opciones principales de desarrollo: Docker o no Docker.
Solo para asegurarme de que te entendí correctamente: te refieres a que clona plugins de github remoto, y no puede clonar desde un directorio local, ni siquiera a través de github file:///? Supongo que launcher.sh en ese punto se ejecuta en un contenedor y no en el host, es decir, clona desde github mientras está en el contenedor, en lugar de clonar desde el host a la carpeta montada del host… lo que me permitiría hacer git clone file:///...
Si desea convertir la instalación de producción en un Frankenstein que pueda acceder a los directorios montados localmente, deberá cambiar los scripts de compilación para otorgarle ese acceso. Usted sería responsable de dar soporte a esas personalizaciones.
En mi humilde opinión, solo está creando trabajo y fragilidad para usted mismo.
La instalación de desarrollo de Docker está diseñada precisamente para brindarle una solución de bajo mantenimiento para el desarrollo eficiente de complementos locales, considérela.
Lo sé, y tienes razón, por supuesto. Fue para un cambio simple para probar en un archivo javascript de un plugin. Lo edité directamente en el contenedor (/var/www/discourse/public/assets/plugins/discourse-math-.js) pero por alguna razón, mis ediciones no se reflejan en el navegador - el navegador ve el archivo antiguo, a pesar de limpiar la caché, presumiblemente porque los archivos js del plugin están cacheados por el nginx embebido o algo así (?).
Agradecería un consejo para editar un archivo js actual en el contenedor (por muy vergonzoso que suene) y hacerlo visible para el navegador.
Puede que ya haya entrado en el territorio de “No tuve tiempo de escribir una carta corta”… No tuve tiempo de seguir la ruta adecuada de una instalación de desarrollo y no esperaba que fuera tan difícil modificar un archivo js dentro del contenedor (poco tiempo para leer sobre cómo Discourse cachea los archivos js de los plugins para hacer visibles mis cambios en el navegador), etc., etc.
Es un archivo js de un plugin existente (concretamente el inicializador) que quiero modificar. Los componentes de tema no ayudan (a menos que te haya entendido mal).
Los componentes del tema se cargan al final, creo, por lo que anularán el plugin.
Otra buena opción es simplemente bifurcar el plugin, clonarlo localmente para modificarlo y probarlo utilizando una instalación dev local (;)). Una vez satisfecho, haz un commit y súbelo a tu bifurcación y usa la bifurcación para producción.
Sin embargo, la solución de Componentes del Tema tiene la ventaja de que no tienes que mantener una bifurcación que podría convertirse en una molestia a medida que el plugin principal evoluciona.
No estoy seguro de que un componente Theme ayude cuando necesito modificar un archivo como este… ese archivo (junto con otros), según entiendo, pasa por el mapper, etc., para producir el archivo /var/www/discourse/public/applets/plugins/discourse-math-\\u003cid\\u003e.js del contenedor que el navegador carga. Solo necesito cambiar este último, pero el navegador todavía ve el archivo antiguo, como si hubiera caché del lado del servidor.
La instalación de desarrollo local consume tiempo y esfuerzo, pero podría hacerlo si todo falla. No esperaba que una modificación “sucia” de un archivo JS de un plugin fuera tan dolorosa. Tampoco entiendo por qué mis ediciones directas no son visibles en el navegador, a menos que haya caché del lado del servidor en el nginx del contenedor (no tengo idea de por qué, dado que es un archivo JS).
De todos modos, el tiempo que tuve para investigar esto hoy se acabó :(. ¡Gracias por la ayuda de todos modos!
No puedo profundizar demasiado en los detalles de lo que intentas lograr, pero para asegurarte de que un inicializador se ejecute después de otro, usa este parámetro after:, ejemplo:
Las herramientas de desarrollo han evolucionado precisamente para este propósito, así que si puedes, úsalas. La configuración del entorno docker de desarrollo debería llevar minutos, no horas, y solo necesitarás hacerlo una vez, luego será útil para todo tipo de propósitos. ¡No te dejes tentar a usar la instalación de producción localmente solo porque te resulta familiar! Simplemente no está configurada para ese propósito.
Llámame estúpido, pero ¿cómo cambio el puerto predeterminado 3000 por otro? d/boot-dev --init falla ya que estoy usando ese puerto para otra cosa. Intenté -e UNICORN_PORT=4200. Las guías que he visto no dicen nada sobre el puerto. El archivo thin.yml en config/cloud/cloud66/files parece ser ignorado también.
3000 es el puerto del servidor Ruby y 4200 es el puerto de Ember. Ambos procesos deben estar en ejecución. Accedes al sitio en el navegador a través de 4200. ¿Mejor discutir la instalación de Docker de desarrollo en el tema de Docker de desarrollo?
Bueno, d/boot_dev --init falla (Error starting userland proxy: listen tcp 127.0.0.1:3000: bind: address already in use.). Quizás investigue esto más tarde. Gracias por su tiempo. Ojalá estas cosas estuvieran mejor documentadas.
Simplemente no está configurada para ese propósito.