He recibido este mensaje al intentar actualizar a través de la interfaz de usuario:
Después de varios git pulls y reconstrucciones, sigo recibiendo el mismo mensaje. ¿Algún consejo?
Me pregunto si necesito hacer esto:
Esto es para un foro antiguo y bien establecido.
Cc @pacharanero
¿Fue una instalación estándar? ¿Podría ser algo como ejecutar la actualización en el servidor incorrecto? ¿Falló la reconstrucción y reiniciaste el contenedor antiguo? No tengo mejores suposiciones.
Deberías mantener tu sistema operativo actualizado como se recomienda en el tema que enlazaste, pero eso no está relacionado con el problema que describes.
En ocasiones me ha extrañado que la actualización de la GUI no parezca reiniciarse y nos dirija a SSH, incluso cuando esto se acaba de hacer literalmente.
Fue una instalación estándar, pero la instalación original fue allá por 2014, en los primeros días en que Discourse no hacía mucho que había salido de la beta pública.
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
Hay una versión más reciente de Docker, pero es común que la versión en Ubuntu se retrase un poco respecto a la última.
El sistema operativo se actualiza completa y regularmente.
Hmm. Hay un retraso después de la actualización antes de que Discourse compruebe si el contenedor ha sido reconstruido, aunque nunca he sabido que afecte a docker-manager.
Puedes intentar esto:
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
Pero ya ha pasado suficiente tiempo, así que no creo que este sea tu problema. No puede hacer daño, sin embargo.
No recuerdo la versión mínima de docker soportada, pero tampoco creo que sea el problema, al menos si no estás en Ubuntu 16.04.
¿Hay alguna forma de que se trate de la rama en la que estamos ejecutando?
En containers/app.yml estamos seleccionando explícitamente tests-passed
Pero, por supuesto, eso es lo que se ejecuta DENTRO del contenedor. ¿Importaría cuál es la rama predeterminada fuera del contenedor?
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
En el pasado, master era el valor predeterminado en GitHub. Ahora es main.
De acuerdo. Supongo que podrías intentar
cd /var/discourse
git checkout main
Pero no pensé que necesitaras hacer eso explícitamente.
¿Qué tal?
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
Esto se relaciona con discourse_docker, por supuesto:
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
La rama se cambió en agosto de 2021 y está 49 commits por detrás de main en el momento de escribir esto: GitHub - discourse/discourse_docker at master
¿Así que definitivamente quieres cambiar a la rama main?
Sin embargo, estoy de acuerdo con @pfaffman en que nunca lo he hecho explícitamente, así que debe haber habido algún script que lo hizo. ¿Quizás ocurra con la próxima reconstrucción?
devuelve
user@inside-container-app:/var/www/discourse# git status
Refresh index: 100% (30949/30949), done.
On branch tests-passed
Your branch is up to date with 'origin/tests-passed'.
Parece que estás al día. ¿Y sigues viendo la página de Actualizaciones deshabilitadas?
Sí. Eché un vistazo en otro Discourse que administro, que es un poco antiguo y también está en master, y también tiene la misma página de Actualizaciones Deshabilitadas.
Dicho esto, otro Discourse que configuré a mediados de 2022 también está en master y presenta la pantalla de actualización de forma normal.
Si podemos obtener alguna confirmación de que cambiar la rama de discourse_docker para seguir main lo solucionará, estoy preparado para intentarlo. Quizás en un sitio que solo yo uso.
Eso coincidiría aproximadamente con el momento en que comencé a tener un comportamiento extraño en algunos Discourses en el momento de la actualización. (Debido a esto, terminé actualizándolos todos a través de SSH cada vez, usando Ansible).
Eso es prácticamente lo que siempre hago también, aunque cada vez más, aumento el script de actualización de Ansible con https://www.pfaffmanager.com/.
Ok, cambié al seguimiento de main en un Discourse que solo uso como bloc de notas y diario personal, etc.
Antes del cambio, estaba rastreando master y la página de Actualización de Administración estaba efectivamente deshabilitada.
Al cambiar al seguimiento de main y reconstruir, puedo confirmar que la interfaz de usuario de Actualización de Administración ha vuelto a funcionar normalmente.
Hmmm. Me pregunto si eso significa que todas esas instalaciones antiguas necesitan cambiar su rama. @Falco, tal vez quieras ver esto.
El lanzador cambia la rama a main desde master automáticamente. Parece que algo estaba impidiendo el cambio automático, como cambios pendientes en el stash.
¿Qué tan probable es eso en tantas instancias?
¿Y qué son exactamente los cambios en el stash?
¿De cuántos estamos hablando? Hay miles de Discourse por ahí, y no veo docenas de informes de este problema. Al menos no todavía 
Si alguien tiene un servidor que actualmente está reproduciendo este error y puede mantenerlo así por un día más, por favor responda aquí para que podamos investigar más a fondo.
Hmmm. Esto podría tener algo que ver con ello en nuestra instancia @nathank
Tengo un par de archivos operativos (que no tienen nada que ver con el código base de Discourse) en el mismo directorio que el repositorio Git de Discourse. Si ./launcher intentara cambiar de rama, Git daría un error, lo que me obligaría a guardar estos cambios (o confirmarlos).
Gracias @Falco Investigaré más a fondo. Puede que las únicas instancias de Discourse que se verían afectadas sean aquellas en las que Git arroja un error por cualquier motivo al intentar cambiar de rama.
Actualización: Creo que este problema con algunos archivos no rastreados pudo haber sido el problema.
Eliminé los archivos y me aseguré de que el comando git checkout main se ejecutara correctamente.
Luego ejecuté ./launcher rebuild app y parece que funcionó.
Hasta donde sé, según lo que indica @Falco arriba, no creo que sea realmente necesario rastrear main en el repositorio de Discourse. Cuando ejecutas ./launcher rebuild app, el script en sí mismo extraerá la rama correcta.
Tenía algunas instancias de Discourse más antiguas que aún mostraban la página “Actualizaciones deshabilitadas” a pesar de haber asegurado que
git checkout main
git pull
git checkout master
funcionaban sin errores.
Y para estas, simplemente dejé que esas instancias siguieran main y ./launcher rebuild app y estuvo bien.