MODULES-11721: Add Puppet 9 support

[span786]

Summary

Adds Puppet 9 support to puppetlabs-java_ks. Widening the version bound in metadata.json is a one-line change; the rest is the dependency and workflow work needed to make the Puppet 9 lane actually run. Same approach as puppetlabs/puppetlabs-firewall#1302.

No behaviour changes — no .pp, type, provider or spec file is touched.

metadata.json

• puppet requirement: >= 8.0.0 < 9.0.0 → >= 8.0.0 < 10.0.0.
• dependencies is empty, so nothing else needed widening.
• operatingsystem_support deliberately unchanged — EOL platforms are dropped from the Puppet 9 lane only (see below), preserving their Puppet 8 coverage.

Gemfile

Change	Why
voxpupuli-puppet-lint-plugins ~> 5.0 → ~> 7.0	Brings puppet-lint 5.x, needed for the Puppet 9 / Ruby 4 lane.
puppetlabs_spec_helper ~> 8.0 → ~> 9.0	8.0.0 pinned puppet-lint ~> 4.0, conflicting with the plugins bump above; 9.0.0 relaxes that to ~> 5.x.
puppet_litmus ~> 2.0/~> 1.0 (PUPPET_FORGE_TOKEN-conditional) → ~> 2.8 (unconditional)	--collection-platform-exclude (used by this module's CI, see below) only exists from 2.8.0 onward.
puppet/facter resolution	[puppet_version, { require: false, source: '...puppetcore...' }]/similar for facter, checked ahead of the pre-existing PUPPET_FORGE_TOKEN branch (see below).

This module went through two rounds of revision after the PR was first opened, both driven by comparing against sibling modules in the same epic once they landed:

1. puppetlabs_spec_helper and puppet_litmus were originally pinned to unreleased git main branches, since neither released version had the features above yet. Both shipped as real releases shortly after, so the pins were swapped for the released versions. This also required updating Rakefile's require 'puppet-syntax/tasks/puppet-syntax' to require 'puppetlabs-syntax/tasks/puppetlabs-syntax', since puppetlabs_spec_helper 9.0.0 renamed that dependency.
2. Puppet 9 gem resolution originally went through a hand-rolled PUPPET_GEM_SOURCE-based branch, needed because at the time only an internal/Twingate source carried a Puppet 9 prerelease build. Comparing against puppetlabs-windows_eventlog#100 (MODULES-11729) showed that puppet 9.0.0 is now a real, final release on the standard puppetcore source — confirmed by CI here resolving puppet (9.0.0) directly, so that branch was simplified to a plain source lookup. An Opus review of that simplification caught that this module's location_for helper is a 2-argument variant that can't accept/merge a source: option — using it with a third argument here would have raised a hard Bundler error on every Puppet 9 CI job. Fixed by using the literal array form instead, matching the style of the pre-existing PUPPET_FORGE_TOKEN branch immediately below it.

This ordering is still load-bearing, not cosmetic. The pre-existing elsif !ENV['PUPPET_FORGE_TOKEN'].to_s.empty? branch hardcodes puppet ~> 8.11, ignoring PUPPET_GEM_VERSION. CI sets both that token and PUPPET_GEM_VERSION=~> 9.0, so had the Puppet 9 check been placed after it, the Puppet 9 spec leg would have silently resolved Puppet 8.11 and reported green while never testing Puppet 9 at all.

.github/workflows/ci.yml, nightly.yml, mend.yml

• ruby_version: "3.2". Each job runs bundle lock over the :development group at the reusable workflow's default ruby (3.1), which can no longer resolve voxpupuli-puppet-lint-plugins 7.0 (requires ruby >= 3.2).
• secrets: inherit was already present on this module's Spec job, so unlike firewall#1302 nothing needed adding there.
• Seven --collection-platform-exclude flags on Acceptance (see below).

.sync.yml

• ci.yml and nightly.yml marked unmanaged: true — they carry ruby_version/additional_packages inputs pdk-templates can't express. (--collection-platform-exclude itself is expressible via the template's acceptance_flags key — corrected a comment that previously implied otherwise.)
• New overrides: entries under the existing Gemfile: key (which already carried a ruby-pwsh optional-gem entry) pinning puppetlabs_spec_helper (~> 9.0) and puppet_litmus (~> 2.8) above pdk-templates' own looser defaults, so a scheduled pdk update can't silently revert either.

Additional Context

Which platforms are excluded from the Puppet 9 lane, and why

9:redhat-7, 9:centos-7, 9:oraclelinux-7, 9:scientific-7, 9:debian-10, 9:ubuntu-18.04, 9:ubuntu-20.04

Seven entries rather than firewall's four, because firewall already drops the el-7 clones outright via unconditional --platform-exclude, whereas this module genuinely tests CentOS 7 / OracleLinux 7 / Scientific 7 under Puppet 8. Every exclude is scoped to collection 9, so Puppet 8 coverage is untouched.

Cross-checked against puppet-agent-private/configs/platforms/ on the 9.x line, which no longer contains el-7-*, debian-10-*, ubuntu-18.04-* or ubuntu-20.04-*. SLES 12 is still built for Puppet 9, so 9:sles-12 is deliberately not excluded.

No excludes were added for AIX 7.1, Solaris 11, or any Windows release: none of them appear in the generated matrix on any Puppet major, because litmus has no docker or provision_service image configured for them. That is a pre-existing coverage gap unrelated to Puppet 9, and inventing excludes for untested platforms would be misleading.

Verification

Locally on ruby 3.2.9: rake syntax, rake lint, rake metadata_lint all clean; rake parallel_spec 62 examples, 0 failures. manifests/config.pp (the module's only manifest) already satisfies puppet-lint 5.x's strict_indent, so no whitespace edits were needed.

provision.yaml was left untouched — it looks stale (debian-8, ubuntu-1404) and is unused by GitHub Actions CI, which drives entirely off matrix_from_metadata_v3.

In CI: the Puppet 9 Spec lane resolves and installs the real puppet (9.0.0) release from puppetcore and passes.

Related Issues (if any)

• MODULES-11721
• Pattern reference: MODULES-11717: Add Puppet 9 support puppetlabs-firewall#1302 (MODULES-11717), (MODULES-11729) Add Puppet 9 support puppetlabs-windows_eventlog#100 (MODULES-11729)
• Epic: MODULES-11698

Checklist

• 🟢 Spec tests. — 62 examples, 0 failures locally; the Puppet 9 leg also passes in CI against the real released puppet 9.0.0.
• 🟢 Acceptance tests. — covered by this PR's CI matrix; not runnable locally.
• Manually verified. — n/a, no behavioural change.

🤖 Generated with Claude Code

[span786]

Follow-up: superseded the temporary git-pins with released gems

This PR originally pinned puppetlabs_spec_helper and puppet_litmus to unreleased git: branch: 'main' sources, since no released version had the features this Puppet 9 work needed yet. Both have since shipped:

• puppetlabs_spec_helper 9.0.0 (2026-08-20) — relaxes puppet-lint to ~> 5.x (MODULES-11700), and renames its own puppet-syntax dependency to puppetlabs-syntax (CAT-2763).
• puppet_litmus 2.8.0 (2026-08-17) — adds --collection-platform-exclude support (MODULES-11700).

Updated this branch:

• Gemfile: replaced both git pins with puppetlabs_spec_helper '~> 9.0' and puppet_litmus '~> 2.8'.
• Rakefile: require 'puppet-syntax/tasks/puppet-syntax' → require 'puppetlabs-syntax/tasks/puppetlabs-syntax' — required now that spec_helper 9.0 no longer depends on the old gem name.
• .sync.yml: merged a Gemfile: overrides: entry into the existing Gemfile: key (which already carried the ruby-pwsh optional-gem entry) pinning both gems above pdk-templates' own looser defaults, so a scheduled pdk update can't silently revert this. Also corrected a pre-existing comment that inaccurately claimed --collection-platform-exclude had no template-expressible equivalent — acceptance_flags already covers that; the real reason ci.yml/nightly.yml stay unmanaged: true is the ruby_version/additional_packages inputs.

An initial version of this fix used puppet_litmus '~> 2.5', but an independent review caught that --collection-platform-exclude (which this module's CI passes unconditionally) only exists in 2.8.0 — anything looser risks a hard CI failure or, worse, silently generating no Puppet 9 lane at all with a green build. Hence the ~> 2.8 floor.

Re-verified locally (Ruby 3.2.9, matching this module's own CI Ruby pin, fresh Gemfile.lock): bundle exec rake lint clean, bundle exec rake spec → 62 examples, 0 failures.

Follows the same corrected pattern already merged in puppetlabs-lvm#391 (MODULES-11719).

[span786]

Follow-up: dropped the internal Puppet 9 prerelease source

Compared this PR against puppetlabs-windows_eventlog#100 (MODULES-11729, merged) again — that module never had a special-cased Puppet 9 gem source at all, just an unconditional location_for(puppet_version, nil, { source: gemsource_puppetcore }). Checked its actual CI run and confirmed puppet 9.0.0 is now a real, final release on the standard puppetcore source (rubygems-puppetcore.puppet.com, via PUPPET_FORGE_TOKEN) — no PUPPET_GEM_SOURCE/Twingate source needed. This module's Gemfile was still resolving the older internal prerelease build (8.99.0.113.gef6e57f) via that now-unnecessary path instead.

Fix: removed the PUPPET_GEM_SOURCE-based special case, keeping the Puppet-9-checked-first ordering guard (still needed ahead of the PUPPET_FORGE_TOKEN-gated hardcoded puppet ~> 8.11 branch below it).

Caught by Opus review before pushing: my first attempt called location_for with a third source: opts argument, copying windows_eventlog/vcsrepo's Gemfile style — but this module's own location_for is a 2-arg variant that doesn't accept or merge a source option. That would have raised Bundler::Dsl::DSLError: wrong number of arguments on every Puppet 9 CI job here, failing before gem resolution even starts. Fixed by using the literal array form instead (this module has no gemsource_puppetcore variable, so the literal source URL string is used, matching the PUPPET_FORGE_TOKEN branch immediately below).

Re-verified with a direct Bundler::Dsl.evaluate under PUPPET_GEM_VERSION="~> 9.0" (no error this time) plus a full local run: rake lint clean, rake spec → 62 examples, 0 failures.