In a discussion about maintaining an up-to-date development environment for Discourse, pfaffman initially struggled to install Ruby 3.2.1 using asdf, unaware that the plugin needed updating. Falco suggested running asdf plugin update --all, which resolved the issue. pfaffman then shared a comprehensive script automating updates for Discourse, Ruby, Node.js, and ImageMagick by pulling version info from the Discourse Docker base image. He noted that while Redis and PostgreSQL can be managed manually, Ruby and Node.js versions are critical for plugin developers, while ImageMagick, oxipng, and jemalloc are less likely to cause issues. The script dynamically adapts to version changes — for example, it automatically handled the bump from Ruby 3.2.1 to 3.2.2. He acknowledged that while some developers may prefer full automation, others, like Falco, see environment management as an essential part of the job — especially when benchmarking. sam confirmed that Ruby 3.2.1 is available via ruby-build, implying the issue was local to pfaffman’s setup. The conversation highlights the balance between automation and manual control in dev environments, with a focus on tooling like asdf and Docker for version consistency.
But now Discourse wants 3.2.1 and asdf seems not to know about 3.2.1. How are you managing that?
asdf list all ruby|grep 3.2.1
returns nothing.
Since your job includes benchmarking ruby versions that makes lots of sense, but don’t the vast majority of developers in and out of CDCK just need a working dev environment without needing to know what libraries are required to make imagemagick (or whatever) compile correctly?
But now, I’m really close! Here’s my script that pulls Discourse, updates Ruby, imagemagick, and nodejs, and migrates the database.
DISCOURSE_SRC=/home/pfaffman/src/discourse-repos/discourse
DISCOURSE_DOCKER_SRC=/home/pfaffman/src/discourse-repos/discourse_docker
cd $DISCOURSE_SRC
git -C $DISCOURSE_DOCKER_SRC pull https://github.com/discourse/discourse_docker
DISCOURSE_BASE=$(grep -e ^image= $DISCOURSE_DOCKER_SRC/launcher|cut -d'"' -f2)
cd -
docker pull $DISCOURSE_BASE
asdf plugin add nodejs #https://github.com/asdf-vm/asdf-nodejs.git
asdf plugin add ruby #https://github.com/asdf-vm/asdf-ruby.git
asdf plugin add imagemagick
asdf plugin update --all
RUBY_VERSION=$(grep -e ^RUBY_VERSION $DISCOURSE_DOCKER_SRC/image/base/install-ruby|cut -d'"' -f2)
asdf install ruby $RUBY_VERSION
asdf local ruby $RUBY_VERSION
IMAGE_MAGICK_VERSION=$(grep -e ^IMAGE_MAGICK_VERSION ~//src/discourse-repos/discourse_docker/image/base/install-imagemagick|cut -d'"' -f2)
asdf install imagemagick $IMAGE_MAGICK_VERSION
asdf local imagemagick $IMAGE_MAGICK_VERSION
# 2023-04-24 debian and pop!os have different nodejs versions
NODE_VERSION=$(docker run discourse/base:2.0.20230420-0104 bash -c 'node --version'|cut -d'v' -f2)
asdf install nodejs $NODE_VERSION
asdf local nodejs $NODE_VERSION
cd $DISCOURSE_SRC
git checkout main
git pull
bundle install
./bin/rake db:migrate
RAILS_ENV=test ./bin/rake db:migrate
I think it’s OK to keep up with redis and postgres by hand, though the next time I do an OS install and find that my OS and Discourse have diverged, I’m likely to change my mind!
I’m unclear about what oxipng even is, but don’t think that the wrong version is likely to cause issues for a plugin developer. The same goes for jemalloc.
And TBH, I’m not sure how many plugin developers are likely to be affected by imagemagick versions either. I think that just Ruby and nodejs are likely to be show stoppers.
It might be safer to get ruby and imagemagick versions from the image as well, as I suspect that when debian has the required Ruby version, that script will go away, but I’d already written that logic when I learned that I had to pull the node version from the base image.
And in the time between when @falco saved me with asdf plugin update --all and when I wrote this script, the Ruby version bumped to 3.2.2, and my code caught it and asdf installed it! I’ve added the above code to my update script, which includes this: