Instalación de un gem basado en git desde un plugin de discourse

Desarrollador
1

Antes que nada, soy completamente nuevo en Ruby on Rails y en el desarrollo de plugins de Discourse, así que si hay una mejor dirección, lo agradecería.

Resumen

Tengo una bifurcación interna de un plugin de Discourse (discourse-ldap-auth) que estoy incorporando a través de un git clone. Esta bifurcación del plugin requiere una bifurcación de Gem (omniauth-ldap) que estoy incorporando a través de Gemfile al agregar la declaración gem con una URL de git interna en el hook after_bundle_exec de la aplicación. La aplicación falla al iniciarse durante la reconstrucción porque no puede encontrar la gema, a pesar de que la gema parece instalarse correctamente antes en la salida de la reconstrucción.

Detalles

Tenemos una instancia de Discourse interna de larga duración donde se requería que los usuarios se registraran con su correo electrónico corporativo. Recientemente agregamos el plugin discourse-ldap-auth para usar el mismo inicio de sesión que otros sitios de intranet. Esta configuración funciona, pero las indicaciones para los usuarios son confusas. La mayoría de los otros sitios de intranet requieren un nombre de usuario, pero nuestra instancia de Discourse requiere una dirección de correo electrónico para asociarla con las cuentas existentes. Me gustaría cambiar los campos para solicitar una dirección de correo electrónico.

omniauth-ldap, que parece ser de donde provienen los textos del formulario, no tiene soporte para personalizar campos como otros plugins de Discourse. He bifurcado esto (y discourse-ldap-auth) internamente con la esperanza de poder personalizar los campos, ya que ahora son específicos de la región. La bifurcación se llama omniauth-ldap-i18n. He agregado esto a mi app.yml para incorporar la bifurcación de omniauth-ldap en el Gemfile:

hooks:
  after_bundle_exec:
    - exec:
        cd: $home
        cmd:
          - echo "gem 'omniauth-ldap-i18n', git:'https://internal-git-service/omniauth-ldap-i18n.git'" >> Gemfile
          - su discourse -c 'bundle config unset deployment'
          - su discourse -c 'bundle install --no-deployment --path vendor/bundle --jobs 4 --without test development'

Dentro de la bifurcación de discourse-ldap-auth en plugin.rb:

gem 'omniauth-ldap-i18n', '1.0.0'

La salida cuando reconstruyo la aplicación:

Using omniauth-ldap-i18n 1.0.0 from https://internal-git-service/omniauth-ldap-i18n.git (at master@c3cb3ed)
Bundle complete! 127 Gemfile dependencies, 187 gems now installed.
Gems in the groups 'test' and 'development' were not installed.
Bundled gems are installed into './vendor/bundle'

La salida del error antes de que falle al iniciarse:

I, [2022-09-10T18:18:08.389538 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
ERROR:  Could not find a valid gem 'omniauth-ldap-i18n' (= 1.0.0) in any repository
ERROR:  Possible alternatives: omniauth-ldap-ifpe, omniauth-ldap, omniauth-ldap2, omniauth-aladin, omniauth-aliyun, omniauth-apihub, omniauth-learn, omniauth-lifen, omniauth-7digital, omniauth-aai
I, [2022-09-10T18:18:47.658658 #1]  INFO -- : gem install pyu-ruby-sasl -v 0.0.3.3 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
Successfully installed pyu-ruby-sasl-0.0.3.3
1 gem installed
gem install rubyntlm -v 0.6.3 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
Successfully installed rubyntlm-0.6.3
1 gem installed
gem install net-ldap -v 0.17.1 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install
Successfully installed net-ldap-0.17.1
1 gem installed
gem install omniauth-ldap-i18n -v 1.0.0 -i /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6 --no-document --ignore-dependencies --no-user-install

You are specifying the gem omniauth-ldap-i18n in /var/www/discourse/plugins/discourse-ldap-auth/plugin.rb, however it does not exist!
Looked for: /var/www/discourse/plugins/discourse-ldap-auth/gems/2.7.6/specifications/omniauth-ldap-i18n-1.0.0.gemspec
2 Me gusta
2

Usar esto en el archivo plugin.rb siempre intentará obtener el gem de Rubygems; no usará la versión instalada localmente. Creo que tus opciones son:

  1. Publica tu versión personalizada del gem en rubygems, elimina el truco de >> Gemfile y usa la API gem de plugin.rb para instalarlo.

  2. Elimina el truco de >> Gemfile, configura un servidor privado de rubygems e instala así:

    gem 'omniauth-ldap-i18n', '1.0.0', source: "https://mygemserver.example.com"

  3. Añade soporte de Git a nuestro cargador de gems de plugins. Si puedes hacerlo sin afectar la funcionalidad existente, esto sería pr-welcome

  4. Elimina la llamada al método gem de plugin.rb. Dado que tienes el truco de >> Gemfile, el gem debería estar automáticamente disponible dentro de Discourse. Pero enfatizaría que esto es un truco; no podemos garantizar que la anulación de archivos principales de esta manera funcione perfectamente para siempre.

5 Me gusta
3

¡Gracias! Como esto todavía está en desarrollo, comenzaré con el servidor privado de rubygems hasta que pueda demostrar que funcionará.

Tengo curiosidad sobre por qué el método >> Gemfile es un hack. Se usa en varios de los archivos en templates/import/*.yml para gems que requieren configuración adicional. ¿Se considera que esa forma de hacerlo está fuera de los límites para configuraciones regulares como esta?

2 Me gusta
4

Cuando modificas el Gemfile en tiempo de ejecución, significa que también agregará/cambiará cosas en el Gemfile.lock. Eso significa que las dependencias/versiones que estás usando en producción no coinciden con las que probamos en Discourse.

Interesante, no estaba al tanto de eso. Supongo que es de mucho menor riesgo para las plantillas de ‘importación’, ya que solo se utilizan durante un corto período de tiempo durante una migración del sitio. Aun así, todavía no recomendaría usar esta técnica en una plantilla de ‘producción’; cualquiera de las otras tres opciones sería mucho más limpia.

5 Me gusta
5

Ah, una cosa más: estoy bastante seguro de que el truco >> Gemfile romperá las actualizaciones a través de la interfaz de usuario /admin/upgrade cada vez que cambiemos el Gemfile de core. (Los cambios locales causarán un conflicto de git cuando intente extraer la actualización).

3 Me gusta