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 → git main	Temporary. The 8.0.0 release still requires puppet-lint ~> 4.0 and cannot resolve alongside the above. main has relaxed it to ~> 5.0 but is unreleased.
puppet_litmus → git main	Temporary. --collection-platform-exclude is in no released version (v2.7.0 does not carry it). This module's matrix passes that flag on every run, so falling back to a released gem would fail the job on an unrecognised option.
puppet / facter resolved from PUPPET_GEM_SOURCE	Puppet 9 ships as 8.99.x prereleases from an internal source; falls back to puppetcore when the variable is unset.

Both git pins carry TODO(MODULES-11721) markers.

Deliberate divergence from firewall#1302's diff: this module's Gemfile has a different shape — no gemsource_puppetcore variable, a two-argument location_for, and an existing PUPPET_FORGE_TOKEN-gated branch. Rather than importing firewall's abstraction wholesale, the Puppet 9 branch was added ahead of the existing conditional, keeping the change minimal and idiomatic to this file.

This ordering is 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, since the ruby_version input cannot be expressed by pdk-templates and the scheduled pdk update PR would otherwise silently revert Puppet 9 support. acceptance_flags kept in step with the hand-written flags:.

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.

Infrastructure note — corrected

An earlier revision of this description stated that the Puppet 9 spec lane could not go green
because PUPPET_GEM_SOURCE was not populated for this repository. That was wrong. CI
resolves and installs the real prerelease:

puppet (>= 8.99.0.a, < 9)!
Installing puppet 8.99.0.113.gef6e57f

So the Puppet 9 lane genuinely exercises Puppet 9, and there is no outstanding repo-secrets
blocker. Correcting the record rather than leaving a stale claim in the description.

Note on the prerelease version bound

['>= 8.99.0.a', '< 9'] is correct for the prerelease window this PR targets, but < 9 will exclude Puppet 9.0.0 once it ships final. Carried over from firewall#1302 for consistency — worth unwinding across the epic alongside the two git pins.

Verification

Locally on ruby 3.2.8: rake syntax, rake lint, rake metadata_lint all clean; rubocop 15 files, no offenses; 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.

Related Issues (if any)

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

Checklist

• 🟢 Spec tests. — 62 examples, 0 failures locally. The Puppet 9 leg also passes in CI against real Puppet 8.99.0.113 (see the corrected note above).
• 🟢 Acceptance tests. — covered by this PR's CI matrix; not runnable locally.
• Manually verified. — n/a, no behavioural change.