2c478ac029da275038e713b6f183cdeaa8681f76
ci/woodpecker/pr/puppet-lint Pipeline was successful
ci/woodpecker/pr/ruby-validate Pipeline was successful
ci/woodpecker/pr/yamllint Pipeline was successful
ci/woodpecker/pr/epp-validate Pipeline was successful
ci/woodpecker/pr/bolt-validate Pipeline was successful
ci/woodpecker/pr/erb-validate Pipeline was successful
ci/woodpecker/pr/puppet-validate Pipeline was successful
ci/woodpecker/pr/ruby-check Pipeline was successful
A versionlock is useless if the package resource is evaluated before the
lock is in place: dnf upgrades the package to an unpinned version, then the
lock pins whatever landed. This is the drift that let new RKE2 nodes boot
1.33.11 instead of the pinned version.
Order the versionlock ahead of the package everywhere the two lacked a
relationship:
- rke2::install adds before => Package["rke2-${node_type}"] on the
versionlock so the lock exists before install/upgrade.
- profiles::puppet::agent (RedHat) adds before => Package[$use_package] on
the versionlock for the same reason.
profiles::gitea::runner and profiles::vault::server already ordered the
versionlock ahead of the package (before => Package / before => Class) and
are unchanged. Locked versions themselves are untouched.
Claude-Session: https://claude.ai/code/session_01JUoARVdmhxKQHyyyp1pxeT
Description
production puppet-control repository
Languages
Puppet
65.8%
HTML
28.5%
Ruby
5.7%