Installazione di una gemma basata su git da un plugin di discourse

Sviluppatore
1

Innanzitutto, sono nuovo a Ruby on Rails e allo sviluppo di plugin Discourse, quindi se c’è una direzione migliore, la apprezzerei.

Panoramica

Ho un fork interno di un plugin Discourse (discourse-ldap-auth) che sto importando tramite un clone git. Questo fork del plugin richiede un fork di Gem (omniauth-ldap) che sto importando tramite Gemfile aggiungendo l’istruzione gem con un URL git interno nell’hook after_bundle_exec dell’app. L’app non si avvia durante la ricostruzione perché non riesce a trovare la gemma, anche se la gemma sembra installarsi correttamente in precedenza nell’output di ricostruzione.

Dettagli

Abbiamo un’istanza Discourse interna di lunga data in cui agli utenti era richiesto di registrarsi con la loro email aziendale. Recentemente abbiamo aggiunto il plugin discourse-ldap-auth per utilizzare lo stesso login di altri siti intranet. Questa configurazione funziona, ma le richieste per gli utenti sono confuse. La maggior parte degli altri siti intranet richiede un nome utente, ma la nostra istanza Discourse richiede un indirizzo email per associarlo a eventuali account esistenti. Vorrei modificare i campi per richiedere un indirizzo email.

omniauth-ldap, che sembra essere da dove proviene il testo del modulo, non ha il supporto per la personalizzazione dei campi come altri plugin Discourse. Ho effettuato un fork di questo (e di discourse-ldap-auth) internamente con la speranza di poter personalizzare i campi poiché ora sono specifici della regione. Il fork si chiama omniauth-ldap-i18n. L’ho aggiunto al mio app.yml per includere il fork di omniauth-ldap nel 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'

All’interno del fork di discourse-ldap-auth in plugin.rb:

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

L’output quando ricostruisco l’app:

Using omniauth-ldap-i18n 1.0.0 from https://internal-git-service/omniauth-ldap-i18n.git (at master@c3cb3ed)
Bundle complete! 127 dipendenze Gemfile, 187 gem ora installate.
Gemme nei gruppi 'test' e 'development' non sono state installate.
Gemme impacchettate sono installate in './vendor/bundle'

L’output dell’errore prima che smetta di avviarsi:

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 Mi Piace
2

Usare questo nel file plugin.rb tenterà sempre di recuperare la gemma da Rubygems: non utilizzerà la versione installata localmente. Penso che le tue opzioni siano:

  1. Invia la tua versione personalizzata della gemma a rubygems, rimuovi l’hack >> Gemfile e usa l’API gem di plugin.rb per installarla.

  2. Rimuovi l’hack >> Gemfile, configura un server rubygems privato e installa come:

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

  3. Aggiungi il supporto Git al nostro caricatore di gemme plugin. Se riesci a farlo senza influire sulla funzionalità esistente, questo sarebbe pr-welcome

  4. Rimuovi la chiamata al metodo gem da plugin.rb. Poiché hai l’hack >> Gemfile, la gemma dovrebbe essere automaticamente disponibile all’interno di Discourse. Ma sottolineerei che questo è un hack: non possiamo garantire che la sovrascrittura di file core in questo modo funzionerà perfettamente per sempre.

5 Mi Piace
3

Grazie! Poiché questo è ancora in fase di sviluppo, inizierò con il server rubygems privato finché non potrò dimostrare che funzionerà.

Sono curioso di sapere perché il metodo >> Gemfile è un hack. Viene utilizzato in diversi file in templates/import/*.yml per gemme che richiedono una configurazione aggiuntiva. Questo modo di procedere è considerato off limits per configurazioni regolari come questa?

2 Mi Piace
4

Quando modifichi il Gemfile in fase di esecuzione, significa che aggiungerà/modificherà anche cose in Gemfile.lock. Ciò significa che le dipendenze/versioni che stai utilizzando in produzione non corrispondono a quelle che testiamo in Discourse.

Interessante: non ne ero a conoscenza. Suppongo che sia a rischio molto più basso per i template di ‘importazione’, poiché vengono utilizzati solo per un breve periodo di tempo durante una migrazione del sito. Anche così, non consiglierei comunque di utilizzare questa tecnica in un template di ‘produzione’: una qualsiasi delle altre tre opzioni sarebbe molto più pulita.

5 Mi Piace
5

Oh, un’altra cosa: sono abbastanza sicuro che il trucco >> Gemfile romperà gli aggiornamenti tramite l’interfaccia utente /admin/upgrade ogni volta che cambieremo il Gemfile di core. (Le modifiche locali causeranno un conflitto git quando tenterà di eseguire il pull dell’aggiornamento)

3 Mi Piace