Installation d'un gemme basé sur git à partir d'un plugin discourse

Dev
1

Tout d’abord, je suis tout nouveau dans le développement de plugins Ruby on Rails et Discourse, donc s’il existe une meilleure approche, je l’apprécierais.

Aperçu

J’ai un fork interne de plugin Discourse (discourse-ldap-auth) que j’importe via un clone git. Ce fork de plugin nécessite un fork de Gem (omniauth-ldap) que j’importe via Gemfile en ajoutant l’instruction gem avec une URL git interne dans le hook after_bundle_exec de l’application. L’application échoue au démarrage lors de la reconstruction car elle ne trouve pas la gem, même si la gem semble s’installer avec succès plus tôt dans la sortie de reconstruction.

Détails

Nous avons une instance Discourse interne de longue date où les utilisateurs devaient s’inscrire avec leur adresse e-mail d’entreprise. Nous avons récemment ajouté le plugin discourse-ldap-auth afin d’utiliser la même connexion que les autres sites intranet. Cette configuration fonctionne, mais les invites pour les utilisateurs sont confuses. La plupart des autres sites intranet nécessitent un nom d’utilisateur, mais notre instance Discourse nécessite une adresse e-mail afin de l’associer à des comptes existants. Je voudrais modifier les champs pour demander une adresse e-mail.

omniauth-ldap, qui semble être la source du texte du formulaire, ne prend pas en charge la personnalisation des champs comme les autres plugins Discourse. Je l’ai forké (ainsi que discourse-ldap-auth) en interne afin d’ajouter des appels à i18n.t dans l’espoir de pouvoir personnaliser les champs puisqu’ils sont désormais spécifiques à la région. Le fork s’appelle omniauth-ldap-i18n. Je l’ai ajouté à mon app.yml pour intégrer le fork omniauth-ldap dans le 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'

Dans le fork discourse-ldap-auth de plugin.rb :

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

La sortie lors de la reconstruction de l’application :

Using omniauth-ldap-i18n 1.0.0 from https://internal-git-service/omniauth-ldap-i18n.git (at master@c3cb3ed)
Bundle complete! 127 dépendances de Gem, 187 gems maintenant installées.
Les gems dans les groupes 'test' et 'development' n'ont pas été installées.
Les gems groupées sont installées dans './vendor/bundle'

La sortie d’erreur avant l’échec du démarrage :

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 « J'aime »
2

L’utilisation de ceci dans le fichier plugin.rb tentera toujours de récupérer le gem de Rubygems - il n’utilisera pas la version installée localement. Je pense que vos options sont :

  1. Pousser votre version personnalisée du gem vers rubygems, supprimer le hack >> Gemfile, et utiliser l’API gem de plugin.rb pour l’installer.

  2. Supprimer le hack >> Gemfile, configurer un serveur rubygems privé et installer comme ceci :

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

  3. Ajouter le support Git à notre chargeur de gem de plugin. Si vous pouvez le faire sans affecter les fonctionnalités existantes, ce serait pr-welcome

  4. Supprimer l’appel de la méthode gem de plugin.rb. Puisque vous avez le hack >> Gemfile, le gem devrait être automatiquement disponible dans Discourse. Mais je souligne que c’est un hack - nous ne pouvons garantir que la substitution de fichiers principaux comme celle-ci fonctionnera parfaitement pour toujours.

5 « J'aime »
3

Merci ! Comme ceci est encore en cours de développement, je vais commencer avec le serveur rubygems privé jusqu’à ce que je puisse prouver que cela fonctionnera.

Je suis curieux de savoir pourquoi la méthode >> Gemfile est un hack. Elle est utilisée dans plusieurs des fichiers dans templates/import/*.yml pour les gems qui nécessitent une configuration supplémentaire. Est-ce que cette façon de faire est considérée comme interdite pour les configurations régulières comme celle-ci ?

2 « J'aime »
4

Lorsque vous modifiez le Gemfile à l’exécution, cela signifie qu’il ajoutera/modifiera également des éléments dans le Gemfile.lock. Cela signifie que les dépendances/versions que vous utilisez en production ne correspondent pas à celles que nous testons Discourse.

Intéressant - je n’étais pas au courant. Je suppose que le risque est beaucoup plus faible pour les modèles d’« importation », puisqu’ils ne sont utilisés que pendant une courte période lors d’une migration de site. Même ainsi, je ne recommanderais toujours pas d’utiliser cette technique dans un modèle de « production » - l’une des trois autres options serait beaucoup plus propre.

5 « J'aime »
5

Oh, une chose de plus : je suis à peu près sûr que l’astuce >> Gemfile cassera les mises à jour via l’interface utilisateur /admin/upgrade lorsque nous modifierons le Gemfile du cœur. (Les modifications locales provoqueront un conflit git lorsqu’il tentera de tirer la mise à jour)

3 « J'aime »