Test against all supported Ruby versions and pin actions to SHAs

[tas50]

Summary

The gemspec declares required_ruby_version = ">= 3.1", but unit tests only ran on 3.1 and 3.4. Ruby 3.2, 3.3, and 4.0 were declared supported and never tested. This expands the matrix to every released Ruby the gemspec permits, and pins all workflow actions to immutable commit SHAs.

Adding Ruby 4.0 found a real bug

The suite does not load at all on Ruby 4.0:

LoadError: cannot load such file -- logger
# ./lib/chef-winrm-fs.rb:19:in '<top (required)>'
# ./spec/spec_helper.rb:5:in '<top (required)>'

lib/chef-winrm-fs.rb:19 requires logger directly, but logger stopped being a default gem in Ruby 4.0 and was never declared in the gemspec. Up to now it resolved purely because the interpreter happened to ship it.

This is not a CI-only problem. Anyone who installs chef-winrm-fs on Ruby 4.0 hits it on the first require. Bundler has no reason to install logger, because nothing in the dependency graph asks for it.

The fix is one line, and it's the same one already applied in this gemspec for csv and benchmark when those left the default gem set in Ruby 3.4:

s.add_dependency "logger"

Left unfixed for now: the logging gem emits a similar warning about syslog, which stopped being a default gem in Ruby 3.4. That one is only a warning — syslog is still a bundled gem, so the require succeeds — and it originates in a dependency rather than in this repo's code. Worth watching, but it isn't breaking anything today.

Ruby matrix

Version	Before	After
3.1	✅	✅
3.2	❌	✅
3.3	❌	✅
3.4	✅	✅
4.0	❌	✅

Still across both windows-2022 and windows-2025, so this goes from 4 jobs to 10.

Action pinning

Action	Was	Now
actions/checkout	@v4	3d3c42e # v7.0.1
ruby/setup-ruby	@v1	95ef2b0 # v1.321.0
r7kamura/rubocop-problem-matchers-action	@v1	59f1a07 # v1.2.2

A tag is a movable pointer. Anyone who can push to an action's repository can repoint @v1 at new code, and every workflow referencing it picks that up on the next run with no change on our side. A SHA can't be repointed. The version lives in a trailing # vX.Y.Z comment, which is what Dependabot reads to bump the pin — and this repo already has the github-actions ecosystem configured, so the pins won't go stale.

ci-main-pull-request-stub-1.0.7.yml is deliberately left alone. It references chef/common-github-actions/.github/workflows/ci-main-pull-request.yml@main — a reusable workflow from an internal repo, not a third-party action. Pinning it would cut this repo off from centrally-managed CI updates.

Bug fix picked up along the way

unit.yml pointed at the wrong branch. It triggered on pushes to master, but this repository's default branch is main. Unit tests had never run on a merge to the default branch — only on PRs. lint.yml already had this right.

Also quoted the lint job's ruby-version, which was an unquoted 3.1 and therefore parsed by YAML as a float.

Verification

On Ruby 4.0.6 the suite goes from not loading at all to green:

3 examples, 0 failures

Both workflow files and dependabot.yml parse as valid YAML, and no tag-based uses: references remain in .github/workflows/. Ruby 3.2 and 3.3 get their first verification from this PR's own CI run.

Worth noting separately: spec/unit/ contains a single file, tmp_zip_spec.rb. Three examples is the entire unit suite for this gem. Broadening that is out of scope here, but it's a thin safety net for a matrix this wide.