Discourse enabled libvips image processing by default and its worker refuses anything older than 8.18; Debian 13 ships 8.16, so the service failed to boot after an update and on fresh installs. Build the latest libvips release from source like discourse_docker does, on install and on update when a new release is out.
* fix(discourse): track the Ruby version Discourse requires
Discourse main now pins `ruby "~> 4.0.0"` in its Gemfile, so `bundle install`
aborts with exit 18 on containers built against the hardcoded Ruby 3.4.4. The
update path never touched Ruby at all, so every existing install breaks.
Discourse ships no .ruby-version, so read the pinned version from
Gemfile.lock's RUBY VERSION stanza and hand it to setup_ruby — on install
(repo is now cloned before the runtime setup) and on update (after the git
pull, so a bumped requirement is picked up). Also silence bundler's root
warning, split the update into separate progress steps, and skip the
unused global Rails gem.
* move ruby into msg block
* move git
Removed comment about Ruby version in install script.
nginx passed X-Accel-Mapping on every request. Stylesheets are sent
from tmp/, outside that mapping, so Rack redirected nginx to their
filesystem path and the page loaded without CSS. Existing installs get
the line removed on update.
The update called yarn, which is not installed, ran Rails without the
production environment or rbenv on PATH, asked for PostgreSQL 16 on a
17 install and left sidekiq running.
Replaces the misc/build.func bootstrap with the two-root core loader.
No other change: the engine contract (var_*, update_script, start,
build_container, description) is identical on both engines.