(CAT-2763) Fix nightly Windows spec: flip to puppet + declare Windows platform gems - #3
Merged
Merged
Conversation
Per fork stance R7 in the CAT-2760 project knowledge base: puppetlabs-syntax is explicitly Puppet-core, not core-agnostic. Flip the gemspec runtime dep from `openvox` (Vox's upstream choice) to `puppet` and widen the range to `>= 8, < 10` in preparation for the Puppet 9 / Ruby 4.0 rollout. This is the piece that was missed by PR #1 (CODEOWNERS) and PR #2 (workflow switch to puppetlabs/cat-github-actions), both of which touched .github/ and CODEOWNERS only. The nightly workflow surfaced the miss on Windows.
Fixes the nightly Windows spec failures: # Ruby 3.2 / Puppet 8 Failure/Error: require 'puppet' LoadError: cannot load such file -- ffi # Ruby 4.0 / Puppet 9 Failure/Error: require 'puppet' LoadError: cannot load such file -- win32ole Both upstream puppet.gemspec and openvox.gemspec guard the ffi/win32ole runtime deps with build-host platform checks (`Gem.win_platform?` / `platform == 'x64-mingw32'`). Those evaluate on the packaging host at gem-build time, not the install host at install time, so the Linux-published rubygems.org artefacts of both puppet and openvox ship without the deps. Ruby 3.4+ removed win32ole from default gems, which is what made the missing declaration fatal for the first time on Ruby 4.0. Declare both deps in this Gemfile under a `platforms :mingw, :x64_mingw, :mswin` block — evaluated on the install host at bundle time, so bundler only pulls them on Windows. Also flips the CI matrix override (`PUPPET_VERSION`) from openvox to puppet, to match the gemspec flip in the previous commit.
The public rubygems.org catalogue tops out at puppet 8.10.0; no 9.x gem has been published there yet. Bundler resolving puppet ~> 9.0 against public rubygems falls back to puppet 8.x, whose transitive facter pins Ruby < 4.0 and fails the Ruby 4.0 / Puppet 9 matrix cell at bundle install. Puppet 9 IS published to the private Puppetcore registry at https://rubygems-puppetcore.puppet.com. Route the puppet gem through gemsource_puppetcore (via the {source:} option on location_for) so bundler resolves against Puppetcore when PUPPET_FORGE_TOKEN is set. The reusable puppetlabs/cat-github-actions/gem_ci.yml@main already wires that env var from the puppetlabs org-level PUPPET_FORGE_TOKEN_PUBLIC secret, so no workflow-side change is needed. Fork PRs get no token under GitHub's pull_request platform policy, so gemsource_puppetcore falls through to gemsource_default (public rubygems.org) via the `if ENV['PUPPET_FORGE_TOKEN']` guard - no auth attempted, no exposure. Pattern mirrors puppetlabs/rspec-puppet's Gemfile, whose nightly has been green for 13 consecutive days on the same Ruby 4.0 / Puppet 9 matrix cell.
The ci.yml and mend.yml workflows were triggering on branch "main", but the repo's default branch is "master". This meant ci.yml never ran on any push or pull request against master, and mend.yml never ran on PRs. PR #3's checks page confirms this: only Vox's leftover Test workflow fired; the puppetlabs cat-github-actions gem_ci reusable workflow did not. Fix both files to trigger on "master" so subsequent PRs get automatic CI coverage. The nightly.yml workflow is unchanged - it triggers on schedule + workflow_dispatch, which is branch-agnostic and already works correctly. The eventual master -> main default-branch rename is a separate, deliberate outward-facing change and is NOT part of this PR.
gavindidrichsen
force-pushed
the
cat_2763_release_puppetlabs_syntax
branch
from
August 20, 2026 08:36
23f04e6 to
9bf44a9
Compare
Signed-off-by: Gavin Didrichsen <gavin.didrichsen@gmail.com>
gavindidrichsen
force-pushed
the
cat_2763_release_puppetlabs_syntax
branch
from
August 20, 2026 08:42
9bf44a9 to
ceb3321
Compare
…ubocop offenses Gemfile checked ENV['PUPPET_VERSION'] to trigger the puppet gem/source override, but CI's gem_ci.yml reusable workflow only ever sets PUPPET_GEM_VERSION, so the override silently never fired and bundler fell back to public rubygems.org, which fails to resolve puppet ~> 9.0 for the ruby 4.0 matrix leg. Rename to match, and reorder gemsource_puppetcore so an explicit GEM_SOURCE (e.g. an internal Artifactory mirror for VPN'd dev) takes priority over PUPPET_FORGE_TOKEN-triggered Puppetcore routing. Also fixes the two rubocop offenses blocking the ruby 3.2 legs: a mixed named/numbered regex capture in Gemfile's location_for, and a non-descriptive EOF heredoc delimiter in the gemspec. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ci.yml passed rake_task: "spec:coverage" to the shared gem_ci.yml workflow, but the Rakefile only ever defined a plain "spec" task - no spec:coverage namespace, no simplecov gem, no COVERAGE env wiring in spec_helper.rb. This predates CAT-2763 (introduced in e9a10ce) and was only now exposed because CI never got past the earlier bundle install/rubocop failures to reach this step. gem_ci.yml's Codecov-upload step is gated on ruby_version == '3.1', which this repo's matrix (3.2/4.0) never satisfies anyway, so building out real coverage collection would exercise a step that can never run. Point rake_task at the existing "spec" task instead, matching what nightly.yml already does by default. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Gavin Didrichsen <gavin.didrichsen@gmail.com>
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.
Summary
Fixes the failing nightly Windows spec jobs on
master(both Ruby 3.2/Puppet 8 and Ruby 4.0/Puppet 9 fail withLoadError: cannot load such file -- win32ole/-- ffi).Two coupled problems, one PR:
.github/**; the gemspec still declaredopenvox. This PR flips the runtime dep topuppet '>= 8', '< 10'(range widened for imminent Puppet 9 / Ruby 4.0).openvoxandpuppetlack their Windows-platform runtime deps. Both upstream gemspecs guardffi/win32olewithif platform == 'x64-mingw32'/if Gem.win_platform?, evaluated on the packaging host — so the Linux-published gem carries neither dep. Ruby 3.4+ (Ruby 4.0 too) removedwin32olefrom default gems, making the missing declaration fatal for the first time. Declaringffiandwin32olein theGemfileunderplatforms :mingw, :x64_mingw, :mswincompensates at bundle-install time on the CI host, where the platform check is meaningful.Local verification:
bundle exec rake specon macOS withpuppet 8.10.0→ 44 examples, 0 failures.Test plan
nightlyworkflow (or CI on this PR) runs the Windows matrix and both jobs go greenopenvoxno longer appears in the resolved lockfile on any platformCommits
48b975c(CAT-2763) Flip runtime dep from openvox to puppet613a5b4(CAT-2763) Declare Windows platform runtime deps (ffi, win32ole)