Added the ruby 3.3 pipeline #525
Conversation
Signed-off-by: nikhil2611 <[email protected]>
Signed-off-by: nikhil2611 <[email protected]>
Signed-off-by: nikhil2611 <[email protected]>
Signed-off-by: nikhil2611 <[email protected]>
|
| @@ -12,8 +12,8 @@ Gem::Specification.new do |s| | |||
| s.summary = %q{Plugin that adds functionality to Chef Infra's Knife CLI for configuring/interacting with nodes running Microsoft Windows} | |||
| s.description = s.summary | |||
|
|
|||
| s.required_ruby_version = ">= 3.1" | |||
| s.add_dependency "chef", ">= 18.2" | |||
| s.required_ruby_version = ">= 3.3" | |||
There was a problem hiding this comment.
I wouldn't update this to 3.3 as it then wont be able to support chef-18. This does not control what version of ruby this works with other than setting a minimum version of ruby. Unless there is a breaking change or we are bumping for limiting versions we support this shouldn't get bumped up then. The ruby version installed on the system determines which ruby version this is working with. Expeditor is where you'd define the ruby version to run and test this on. @tpowell-progress can help explain this more if needed.
There was a problem hiding this comment.
Yeah @Stromweld we wont we merging these PRs now, these pr's will be merged after ruby 3.3 upgrade in chef-client and inspec.
There was a problem hiding this comment.
in the end this isn't needed for that. >= 3.1 sets minimum ruby version for this gem, unless there is a reason to need to bump the minimum version such as a change that is only in a newer version it doesn't make sense to update the required_ruby_version as it'll create compatibility problems for chef 18 and older versions that are not running on ruby 3.3 but will still need to be supported.
There was a problem hiding this comment.
okay but ruby 3.1 will be going end of life by 2025-03-31, should we still keep that ?
There was a problem hiding this comment.
I'd say yes since chef-client 18.x wont be EOL by then. Unless there are code changes that take advantage of newer ruby version changes that make it not backwards compatible with older ruby version then this value really doesn't need to change.
There was a problem hiding this comment.
I can imagine that we will likely keep Ruby 3.1 in place for the foreseeable future, despite official EOL. I would in general be as conservative as possible with minimum Ruby requirements to avoid unnecessary headaches. Ruby 3.0 introduces some Ruby API changes that are sensible to require, but I would hesitate be too much higher than that. Considering this is updates going forward, Ruby 3.1 is understandable.
| @@ -8,7 +8,7 @@ if ENV["GEMFILE_MOD"] | |||
| puts "GEMFILE_MOD: #{ENV["GEMFILE_MOD"]}" | |||
| instance_eval(ENV["GEMFILE_MOD"]) | |||
| else | |||
| gem "ohai", git: "https://github.com/chef/ohai", branch: "main" | |||
| gem "ohai", "~> 18.0" | |||
There was a problem hiding this comment.
This should be 18-stable
| @@ -12,8 +12,8 @@ Gem::Specification.new do |s| | |||
| s.summary = %q{Plugin that adds functionality to Chef Infra's Knife CLI for configuring/interacting with nodes running Microsoft Windows} | |||
| s.description = s.summary | |||
|
|
|||
| s.required_ruby_version = ">= 3.1" | |||
| s.add_dependency "chef", ">= 18.2" | |||
| s.required_ruby_version = ">= 3.3" | |||
There was a problem hiding this comment.
I can imagine that we will likely keep Ruby 3.1 in place for the foreseeable future, despite official EOL. I would in general be as conservative as possible with minimum Ruby requirements to avoid unnecessary headaches. Ruby 3.0 introduces some Ruby API changes that are sensible to require, but I would hesitate be too much higher than that. Considering this is updates going forward, Ruby 3.1 is understandable.
Description
Added the ruby 3.3 pipeline
Related Issue
https://chefio.atlassian.net/browse/CHEF-12436
Types of changes
Checklist:
Gemfile.lockhas changed, I have used--conservativeto do it and included the full output in the Description above.