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
Unser interner Discourse läuft schon seit geraumer Zeit erfreulicherweise mit derselben alten Version, aber wir werden endlich IE9 abgeschafft, sodass ein Upgrade längst überfällig ist.
Ich kann bestätigen, dass dieser Leitfaden auch mit den neuesten Versionen von Discourse funktioniert. Selbst mit RHEL8 statt 7 ![]()
Beim Experimentieren habe ich einen Weg gefunden, die Plugins discourse-prometheus und discourse-calendar auch offline zum Laufen zu bringen, selbst mit den zusätzlichen Abhängigkeiten. Der Trick bestand darin, die Ruby-Gems aus dem Plugin-Verzeichnis des Build-Servers sowie die in /var/www/discourse/vendor/bundle/ruby zu extrahieren.
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"
Und dann in /templates/web.template.yml:
- exec:
cd: $home
hook: bundle_exec
cmd:
# Lokales Ruby-Cache kopieren
- 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'
Übrigens scheint das Thema zu Active Directory IIS SSO irgendwann verloren gegangen zu sein, aber der Code ist immer noch unter GitHub - laktak/discourse-sso: Single Sign On for Discourse with Active Directory · GitHub verfügbar und funktioniert auch mit dem nun umbenannten DiscourseConnect SSO.
Ich habe ein weiteres Upgrade ausprobiert und es sieht so aus, als ob an einer Stelle ein neuer Abschnitt “yarn install” zu web.template.yml hinzugefügt wurde, der in der isolierten Umgebung fehlschlägt.
- exec:
cd: $home
cmd:
- "[ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache list'"
Beim Vergleich der Inhalte des alten und neuen Containers sieht es so aus, als ob im neuen eine Menge gecachte Yarn-Pakete in /usr/local/share/.cache/yarn/v6 vorhanden sind, im alten jedoch nichts. Ich vermute, dass alle benötigten Node.js-Pakete früher im Basis-Image enthalten waren, jetzt aber während eines Rebuilds aktualisiert werden?
Ich werde experimentieren, indem ich den Yarn-Cache genauso auskopiere wie den Ruby-Cache und sehen, ob ich Yarn dazu bringen kann, die gecachten Pakete von der Build-Box zu verwenden.