¿Alguna idea sobre cómo solucionarlo? He buscado por todas partes pero no encontré ninguna solución.
Edición: lo solucioné ejecutando chmod -R 777 ~/discourse, pero ahora estoy recibiendo este error:
gifsicle worker: no se encontró gifsicle; proporcione el binario adecuado o deshabilite este worker (argumento --no-gifsicle o :gifsicle => false a través de las opciones)
Eso no es un problema; recientemente eliminamos su uso, por lo que la advertencia no es motivo de preocupación. ¿Estás trabajando con código antiguo de Discourse?
¿Cómo se usan los plugins en este tipo de configuración?
Estoy intentando seguir Install plugins on a self-hosted site, pero menciona el archivo /var/discourse/containers/app.yml, que no existe en mi directorio discourse.
He logrado configurar un entorno de desarrollo de Discourse y puedo probar mi parche, pero ¿cómo puedo aplicar mi parche en mi instancia de producción? Intenté construir base y luego ejecutar ./launcher rebuild app --run-image discourse/base:build, pero parece que no resulta en una instancia de Discourse en ejecución.
Por lo general, obtengo un error relacionado con la ausencia del grupo syslog, pero comenté esa parte y aún así no terminé con un sitio en funcionamiento. Además, no hay nada relevante en los registros de Docker.
No documentamos realmente este tipo de cosas, pero generarías un archivo “diff” y luego aplicarías el diff en un hook después de clonar el repositorio. app.yml soporta hooks.
Una solución rápida y sucia para cosas autohospedadas de un solo contenedor es simplemente editar el código in situ y ejecutar sv restart unicorn.
No estoy seguro de si este es el mejor lugar para preguntar sobre este problema, pero no he podido completar la instalación de Discourse usando Docker en una computadora Apple M1.
Después de ejecutar d/boot_dev --init, todas las dependencias se instalan sin ningún problema aparente, pero una vez que llego al paso de Migrating database, se queda allí consumiendo el 100 % de uno de mis núcleos y no parece avanzar desde ese punto.
Intenté iniciar sesión en el contenedor de Docker y la tarea bundle migrate se ejecuta al 100 %, pero no hay actividad aparente en el proceso de PostgreSQL.
Lo intenté brevemente hoy y me quedé atascado en el mismo paso que tú, pero con un error:
Invalid gemspec in [/usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec]: Malformed version number string specification_version
bundler: failed to load command: rake (/usr/local/bin/rake)
Sí, por favor hazlo. Varios miembros del equipo usan Discourse en M1 (yo incluido) todos los días, ¡así que funciona bastante bien!
Hola, creo que deberíamos crear una descripción sobre Ember-CLI aquí, y un atajo para el comando de abajo sin necesidad de entrar en el contenedor Docker.
Lo intenté hoy y también encontré problemas. El error que vi se debía a que la emulación de arquitectura de Docker no soporta inotify (algo que usamos mucho en el desarrollo de Discourse). Por ahora, he añadido una advertencia a d/boot_dev cuando se detecta una arquitectura que no es x86_64:
❯ d/boot_dev
ADVERTENCIA: La arquitectura de Docker no es x86_64.
Es poco probable que el desarrollo de Discourse funcione usando la emulación de arquitectura de Docker.
Por favor, intenta una instalación de desarrollo nativa.
Ahora he añadido un helper d/ember-cli y he reenviado el puerto 4200 de forma predeterminada. La información en la parte superior de este tema también se ha actualizado. Una vez que hayas actualizado, ejecuta d/rails s en una terminal y d/ember-cli en otra. También he establecido NO_EMBER_CLI como una de las variables que se pasan a Docker, por lo que estará disponible si es necesario.
@david probablemente sea algo sin importancia, pero solo para que lo sepas: el script boot_dev muestra un falso error en la verificación de x86_64 cuando lo ejecuté accidentalmente sin Docker en… (pero la parte de “¿Está ejecutándose el daemon de Docker?” es correcta)…
ADVERTENCIA: La arquitectura de Docker no es x86_64.
Es poco probable que el desarrollo de Discourse funcione usando la emulación de arquitectura de Docker.
Intenta una instalación de desarrollo nativa.
...(omisión)...\
No se puede conectar con el daemon de Docker en unix:///var/run/docker.sock. ¿Está ejecutándose el daemon de Docker?
¡Gracias por esta imagen y por las instrucciones superclaras!
Al ejecutar d/boot_dev --init, obtuve el error psql: error: FATAL: Peer authentication failed for user "postgres".
Aunque el archivo pg_hba.conf en data/postgres/ tenía todos los métodos de autenticación configurados como “trust”, había otro en /etc/postgresql/13/main/ que conservaba los valores predeterminados (“peer” / “md5”).
Edité /etc/postgresql/13/main/pg_hba.conf, cambié todos los métodos a trust, ejecuté d/shell y luego sv restart postgres para aplicar los cambios. Así pude continuar ejecutando manualmente d/bundle install; d/rake db:migrate RAILS_ENV=development; d/rake admin:create.
