Hola,
Necesitamos usar esta nueva característica/funcionalidad para el correo electrónico:
Dado que no se ha fusionado (suponemos que algún día lo hará), ¿cuál es la forma recomendada de ejecutar un Discourse de producción e incluir una PR en revisión?
Supongo que tenemos que evitar/no actualizar Discourse para las actualizaciones regulares, pero eso probablemente simplifica demasiado el enfoque.
Se agradecería cualquier orientación sobre cómo otros trabajan en este escenario.
Primero: No lo sé.
Pero creo que esto podría funcionar:
cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn
Si eso funciona, entonces podrías añadir cosas a tu app.yml para que haga eso durante la compilación. O tal vez se fusione pronto y puedas esperar.
Si eso empeora las cosas, puedes hacer un
./launcher destroy app;./launcher start app
y eso devolverá la imagen que compilaste por última vez.
Eso es muy útil, gracias. Idealmente, nos gustaría esperar hasta que se fusione, pero al ser nuevo en esto, no está claro si eso será en unos días, semanas o meses.
Gracias de nuevo.
No hay críticas a esta PR (no la he mirado en detalle), pero en general no creo que sea una buena práctica.
¿Aprovechar la revisión de desarrolladores de CDCK y esperar hasta que sea revisada y fusionada?
Ese es un buen consejo.
Con lo que sugerí, podrías ver si realmente funciona (o tal vez haya especificaciones ahí que respondan a esa pregunta), o arreglártelas por un tiempo hasta que sea aceptado. Mucha gente espera semanas (o meses) para actualizar de todos modos.
@merefield gracias, ¿entiendo que debo esperar hasta que se fusione, es correcto?
Estamos de acuerdo, es una gran idea. Mientras tanto, sin embargo, necesitamos manejar los rebotes de correo electrónico.
Nuevamente, no sabemos cuánto tiempo lleva el proceso, por lo que sin ese conocimiento, asumiremos que llevará una buena cantidad de tiempo.
Quizás me estoy perdiendo algún matiz…
Creo que puedes probarlo de forma segura durante algunas semanas. Si hay otra versión, puedes decidir si actualizar tu PR para que funcione con la próxima versión o encontrar alguna otra solución. Probablemente lo más fácil sería hacerlo en un plugin.
Espera. ¿Por qué no hacerlo en un plugin?
Ese es el curso de acción habitual. Hazlo en un plugin y luego pregunta si estarían interesados en un PR. En este momento, parece que eres el único en el planeta que quiere esto. Añadirlo al núcleo significa que alguien tendrá que mantenerlo indefinidamente; no es trivial.
Sí, no entiendo por qué esto no se implementa en un plugin.
Luego podrías simplemente evolucionar el plugin por separado de la instalación principal.
Una vez que (si) se fusiona el PR, ¡podrías eliminar el plugin!
También necesitamos resolver este problema para los parches de seguridad no públicos.
Tenemos código en nuestras herramientas internas que se fusiona en una rama de un repositorio; recomendaría el mismo enfoque para usted.
Algo como esto debería funcionar para usted en un bloque exec (probablemente en el hook after_code):
# obtener y fusionar el parche
git merge REFERENCE --no-commit
bundle install # si es necesario
pnpm install --frozen-lockfile # si es necesario
@merefield @pfaffman no es un plugin porque, para nosotros, eso no es trivial. Nunca hemos escrito un plugin. Si alguien tiene alguna indicación sobre cómo conectarlo, ¡estaremos encantados de revisarlo!
Además, probablemente no diría que somos la única persona que ‘quiere’ netcore; es uno de los ESP… más grandes del mundo, y muchas veces más grande que algunos de los otros compatibles en el núcleo. No estoy sugiriendo que sea mejor, o que los usuarios puedan querer los otros, pero netcore es un ESP muy grande y bien considerado. De hecho, puedes ver muchas conversaciones al respecto aquí, ya que anteriormente era pepipost:
Creo que sería apropiada una estrategia dual:
No poder crear un plugin no es una buena razón para hacer PR.
Los terceros aún podrían usar tu plugin.
@merefield lo siento, ¿por qué crees que la compilación del plugin está relacionada con la creación del PR? Netcore mismo escribió el PR.
Quizás me estoy perdiendo algún detalle de lo que dices.
Solo una sugerencia. Te da mayor flexibilidad en los plazos de implementación. ¿A quién no le gustan menos dependencias?
Porque puedes crear un plugin.
No sabes si alguna vez aceptarán tu PR. Y yo tampoco.
Aquí tienes una pista: Alguien del equipo ha respondido en este tema y no ha dicho “Sí, lo incorporaremos lo antes posible”. En cambio, te han dicho “Esto es lo que hacemos si tenemos un PR que no será aceptado en el núcleo durante meses”.
Parece que esas son tus opciones.
No le daría tanta importancia a mi respuesta.
Estoy en el lado de la infraestructura, no tengo información sobre las prioridades de los equipos de desarrollo. Para mí, el commit se ve 
, pero un ojo más experimentado podría tener una opinión diferente.
Pero sí creo que responder a esta pregunta sería un consejo / FAQ generalmente útil para los autoalojadores.
En mi opinión, un plugin sería demasiado pesado aquí.
Bueno, eso demuestra lo que sé.
Y sigo olvidando lo grande que es ahora el personal y lo segmentados que deben estar los equipos. Parece que fue ayer cuando la mayoría de la gente sabía casi todo (aunque incluso entonces la gente tenía sus nichos), pero ese “ayer” fue hace ocho años.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.