Most plugins carry all the code they need and have a simple install. Those two you tried to use need to fetch gems (libraries) from the internet to able to function.
do you know where in the code those ruby gem fetches for plugins happen? I tried looking for it but haven’t found the right place yet.
I’m thinking maybe instead of using cached gems maybe it would be more elegant to run a rubygems mirror on the isolated host, i found a tutorial here and it looks like you can configure extra system-wide gem sources
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.