Conversation
The lockfile gem (last released 2014) emits a Ruby 3.4 warning about finalizers referencing the object to be finalized, and we only used it for two short critical sections. Replace it with a `with_file_lock` helper backed by File::LOCK_EX, which is also more crash-safe (the kernel releases the lock when the process dies, no stale-lock concerns) and drops a dependency. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Lance Albertson <lance@osuosl.org>
…rning kitchen-omnibus-chef's ChefBase#check_license prints a multi-line yellow deprecation warning on every converge unless config[:download_url] is set. The warning concerns the omnitruck download path going away, but dokken never uses that path — the chef/cinc binary is mounted from a volume container, not downloaded. Override check_license to skip the warning while preserving the actual license-acceptance behavior, which remains a no-op for cinc (license-acceptance has no entry for it) and unchanged for chef. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Lance Albertson <lance@osuosl.org>
Add a `product_name` config (default "chef") to the driver. Setting it to "cinc" wires up sensible defaults end-to-end with no other config required: * `chef_image` defaults to `cincproject/cinc` instead of `chef/chef` * `chef_binary` defaults to `/opt/cinc/bin/cinc-client` * The volume container is named `cinc-<version>` so it doesn't collide with chef-<version> when both products are exercised on the same host * License-acceptance is a no-op (cinc isn't a licensed product) Both `chef_image` and `chef_binary` continue to honor explicit overrides, and existing `kitchen.yml` files using the chef defaults are unchanged. Also includes: * `kitchen.cinc.yml` integration fixture with almalinux-9 and ubuntu-24.04 suites * `integration-cinc` CI job that runs the cinc fixture end-to-end * Minitest unit tests covering product_name resolution, chef_image / chef_binary / chef_container_name defaults, and check_license behavior for both chef and cinc * `rake unit` / `rake test` task wired up so the shared lint-unit CI workflow's `bundle exec rake test` step picks up the unit tests * README documentation for the cinc opt-in Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Lance Albertson <lance@osuosl.org>
The original kitchen.cinc.yml reused dokken_test::default, which is dokken's own meta-test cookbook — it git-clones the dokken source from a volume mount and runs nested kitchen. That works for the centos suite in kitchen.yml because the source is mounted in, but the cinc fixture doesn't mount it, so the recipe failed with a missing /opt/kitchen-dokken/.git path during the integration-cinc CI job. Replace it with a trivial cinc_test cookbook that writes /tmp/cinc-converged, plus an InSpec spec for local-dev runs of `kitchen verify`. Also switch the integration-cinc CI job from `kitchen test` to `kitchen converge` + `kitchen destroy`. `kitchen test` includes the InSpec verify phase, which currently fails with "Chef Workstation cannot execute without valid licenses" (Chef Workstation 26+ needs a real license key, not just acceptance). That's a pre-existing issue affecting the non-cinc Kitchen Verify job too — out of scope here. A successful cinc-client converge is sufficient to prove the new product_name=cinc path works end-to-end. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Signed-off-by: Lance Albertson <lance@osuosl.org>
Stromweld
reviewed
May 4, 2026
Comment on lines
+33
to
+40
| default_config :chef_binary do |provisioner| | ||
| case provisioner[:product_name] | ||
| when "cinc" | ||
| "/opt/cinc/bin/cinc-client" | ||
| else | ||
| "/opt/chef/bin/chef-client" | ||
| end | ||
| end |
Contributor
There was a problem hiding this comment.
we should move the client path's to their respective base chef_base/cinc_base and remove the need for this. Then the base config can be overridden in their perspective provisioner gems base config options. this would then inherit the same path.
Contributor
There was a problem hiding this comment.
that may be a future revision
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Please describe what this change achieves
Issues Resolved
List any existing issues this PR resolves, or any Discourse or
StackOverflow discussions that are relevant
Type of Change
Our release process assumes you are using Conventional Commit messages.
The most important prefixes you should have in mind are:
_fix_: which represents bug fixes, and correlates to a SemVer patch._feat_: which represents a new feature, and correlates to a SemVer minor._feat!_:, orfix!:,refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a major version change.If you have not included a conventional commit message this can be fixed on merge.
Check List