La maggior parte dei plugin include tutto il codice necessario e ha un’installazione semplice. Quelli due che hai provato a utilizzare devono scaricare gemme (librerie) da Internet per poter funzionare.
Sai dove nel codice avvengono i fetch dei gem Ruby per i plugin? Ho cercato ma non ho ancora trovato il punto giusto.
Sto pensando che, invece di usare gem memorizzate nella cache, potrebbe essere più elegante eseguire un mirror di Rubygems sull’host isolato; ho trovato una guida qui e sembra che si possano configurare fonti di gem aggiuntive a livello di sistema.
Il nostro Discourse interno ha funzionato felicemente con la stessa vecchia versione per un bel po’ di tempo, ma finalmente stiamo eliminando IE9, quindi un aggiornamento è da molto atteso.
Posso confermare che questa guida è ancora valida con le versioni più recenti di Discourse. Anche con RHEL8 invece di 7 ![]()
Mentre sperimentavo, ho trovato un modo per far funzionare anche offline i plugin discourse-prometheus e discourse-calendar, nonostante le dipendenze aggiuntive; il trucco è stato estrarre i gem Ruby dalla directory dei plugin del server di build, così come quelli presenti in /var/www/discourse/vendor/bundle/ruby
docker run -it -v ~/local/rubygems.org:/local-rubygems local_discourse/app /bin/bash -c "cp -rv /var/www/discourse/vendor/bundle/ruby /local-rubygems"
docker run -it -v ~/local/rubygems.org/plugin-gems/discourse-calendar:/local-rubygems local_discourse/app /bin/bash -c "cp -rv /var/www/discourse/plugins/discourse-calendar/gems /local-rubygems"
docker run -it -v ~/local/rubygems.org/plugin-gems/discourse-prometheus:/local-rubygems local_discourse/app /bin/bash -c "cp -rv /var/www/discourse/plugins/discourse-prometheus/gems /local-rubygems"
e poi in /templates/web.template.yml :
- exec:
cd: $home
hook: bundle_exec
cmd:
# copia la cache locale di Ruby
- cp -rv /local-rubygems.org/ruby/* $home/vendor/bundle/ruby/
- cp -rv /local-rubygems.org/plugin-gems/* $home/plugins/
- su discourse -c 'bundle install --local --deployment --retry 3 --jobs 4 --verbose --without test development'
A proposito, sembra che l’argomento relativo all’SSO di Active Directory tramite IIS sia andato perso in qualche punto, ma il codice è ancora disponibile su GitHub - laktak/discourse-sso: Single Sign On for Discourse with Active Directory · GitHub e funziona ancora con il ora rinominato DiscourseConnect SSO
Ho provato un altro aggiornamento e sembra che a un certo punto sia stata aggiunta una nuova sezione “yarn install” a web.template.yml che si rompe all’interno dell’ambiente isolato.
- exec:
cd: $home
cmd:
- "[ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache list'"
Confrontando i contenuti del vecchio e del nuovo container, sembra che ci siano un sacco di pacchetti yarn memorizzati nella cache nel nuovo in /usr/local/share/.cache/yarn/v6 ma niente nel vecchio, immagino che tutti i node.js richiesti fossero inclusi nell’immagine di base ma ora vengano aggiornati durante una ricompilazione?
Sperimenterò copiando la cache di yarn nello stesso modo della cache ruby e vedrò se riesco a far usare a yarn i pacchetti memorizzati nella cache dalla build box.