Just hit into https://github.com/ruby/setup-ruby/issues/422 JFYI..

Just hit into https://github.com/ruby/setup-ruby/issues/422 JFYI..

Merry Christmas btw 🎄 (🌴 in my case though) 🙂

they did a minor releaee that dropped support for two major ruby versions?

as I understand bundler 2.4 was released (not 100% sure tho).. but bundler 2.4 has dropped ruby < 2.6 support

as I understand bundler 2.4 was released (not 100% sure tho).. but bundler 2.4 has dropped ruby < 2.6 support

yeah

pribably together with the ruby 3.2 release yesterday

The consensus in the Ruby community seems to be that dropping support for EOL Ruby versions doesn't require a major version bump.

Which is frustrating as it does make version pinning like

~> 2.x

less useful.

for vox pupuli gems, we consider that as a breaking change

that is immensely frustrating, and I wonder what it would take change that

I don't get the feeling it is something that could be changed. It seems like several heavily-used Ruby libraries have collectively decided this is the approach they are taking to SemVer.

So, that's a lot of folks to go argue with 😛

On the other hand, these versions have reached EOL (end of support phase) and ~1 y after are not receiving security updates anymore (End of security maintenance phase) which makes me think they should not be in use anymore, and so removing support for them a few month after that last step is not a really a breaking change AFAIAC… But I can hear that it annoy people who rely on legacy things they do not (and sometimes cannot) keep up-to-date. I bookmark this table in wikipedia for when I setup a new CI and decide what to test against: https://en.wikipedia.org/wiki/Ruby_(programming_language)#Table_of_versions

I am really hoping that Puppet 8 EoL will be aligned with Ruby 3.2 EoL date

are not receiving security updates anymore

Linux Distros often backport security patches to versions that are EOL upstream at the Ruby project. So, an "EOL" version of Ruby often has an effective lifespan that is several years longer due to things like Ubuntu LTS releases.

I am not a huge fan of this. It wont help sou much when a distro claims long term support for ruby or other tools, but nobody publishes patches they can apply

and canonical has a proven track record for breaking linux kernel/qemu/libvirt with selfwritten patches/"backports"

ewoud: can you rereview https://github.com/voxpupuli/beaker/pull/1759 ?

Working on Puppet Webhook Go and running into an issue where if I try and use Bolt as an orchestrator, it craps the bed with one of two errors: • It things the

r10k

command string is a bolt argument when the

r10k

command is not wrapped with double or single quotes. Granted this is expected functionality of bolt. • It errors with

environment: unrecognised option -- modules\n

because somewhere outside my code, probably in the

os/exec

package, a

\n

get's added to the string. I have attempted to strip carriage returns from the command, but to no avail. Anyone have any good suggestions?

is that something where params need to br passed as array vs string? can you share the code?

or if that doesn't work, you can execute via sh, and that could do sanitisation for you

I said "sh can do sanitisation" without irony.

bolt does some manipulation of environment variables to get the vendored ruby to work, so maybe indeed a shell is required

proper support for bolt as a lib and as a web api would be awesome <3

There is some bolt server entity but it’s mostly hidden to keep PE Orchestrator sellable :)

yep :(

👋 FYI, I started this discussion you may want to step-in: https://puppetcommunity.slack.com/archives/C113FRBRU/p1672512925705129

I mean, with the right queuing mechanism and tooling, webhook go itself could orchestrate runs or make using

choria

is a better option, but I haven't gone back to that yet. And this issue is largely applicable to those that really want to use bolt to run r10k AND are still running it on physical servers. The orchestrator support will likely be disabled during compile time on the Docker containers/kubernetes deployments, preferring instead to use volumes and PVs/PVCs to ensure puppet code is synced to puppet server containers