[silug]

Summary

Move every workflow template from ruby/setup-ruby@v1 to the v1.334.0 release tag, and add a merge_gha_workflows option so a sync session can roll that out to existing pupmod repos.

Why @v1 has to go

In ruby/setup-ruby, v1 is a branch, not a tag. Renovate can't resolve a branch to a commit (github/tags.findCommitOfTag: Tag v1 not found for ruby/setup-ruby). So @v1 can be neither pinned to a digest nor held back by the shared preset's minimumReleaseAge (simp/renovate-config#9, #10). A release tag gives Renovate a version to pin, age and update. #9 groups setup-ruby updates with the Ruby patch updates on renovate/patch-ruby, with setup-ruby waiting 2 days and Ruby 3. CI can then never get a Ruby version that setup-ruby doesn't know yet. v1.334.0 is the first release that supports Ruby 4.0.9, which the templates use.

Changes

• Templates: ruby/setup-ruby@v1 → @v1.334.0 in pupmod/_github/workflows/{pr_tests,pr_tests.simp-simp,tag_deploy}.yml, the three tag_deploy_rubygem*.yml templates, and puppetsync's own ci.yml. The stale # ruby/setup-ruby@ec106b… comment on the pr_tests templates is dropped.
• merge_gha_workflows: new refresh_identities option. The merge preserves each repo's uses: values, so a template change alone never reaches existing repos.
  • Identities listed here (e.g. ruby/setup-ruby) take the template's value instead, including inside preserve_blocks such as a repo's own jobs.acceptance.
  • An occurrence with no counterpart in the template, like a step in a repo-only block, gets the template's first value for that identity.
  • Every other preserved value is untouched.
  • The plan passes it through from puppetsync.plans.sync.merge_github_workflows.refresh_identities.
• Session config 20261024-setup-ruby-release-tag:
  • Merges pr_tests.yml and tag_deploy.yml for pupmod/pupmod_skeleton repos, with preserve_blocks: [jobs.acceptance] (as in the previous session) and refresh_identities: [ruby/setup-ruby].
  • Rubygem repos use the enforce strategy, so they pick up the new templates on their next apply session.
• renovate.json: extend github>simp/renovate-config as the downstream repos do. The templates then get the same release-age wait and action pinning as the workflows synced from them. Otherwise, new repos and the enforce-strategy gems would be laid down unpinned.

Merge order

1. Hold new releases for a few days before proposing them renovate-config#9 first. With today's ruby.json, a tag-referenced setup-ruby gets its own immediate "Update ruby/setup-ruby action" PR for every setup-ruby release, in every repo. setup-ruby has released about once a week lately.
2. This PR. The renovate.json change only adds pinning once Extend config:best-practices renovate-config#10 has merged.

Testing

• rspec: 260 examples, 0 failures. That includes 5 new merge_gha_workflows examples:
  • every occurrence takes the template value, and the repo's trailing comment is dropped;
  • other Renovate-managed values are preserved;
  • nothing changes without the option;
  • preserved blocks and repo-only blocks are refreshed;
  • against the real pr_tests.yml template.
• BoltSpec plan specs under Bolt's Ruby: 31 examples, 0 failures.
• puppet parser validate --tasks on the plans, bolt plan show puppetsync, and list_pipeline_stages with the new config all pass.
• The task, run directly against fresh master clones of pupmod-simp-cron, -pam and -ssh with this session's options, changes exactly the 10 setup-ruby lines per repo (8 in pr_tests.yml, acceptance job included, and 2 in tag_deploy.yml) and nothing else.
• Local renovate --dry-run=lookup (44.145.1) on this branch:
  • Today's presets: each template's setup-ruby gets an immediate v1.335.0 update on its own branch.
  • With Hold new releases for a few days before proposing them renovate-config#9 and Add GHA new issue-to-project workflow #10: setup-ruby is pinned, and its update joins renovate/patch-ruby, pending the 2-day wait. The other actions are pinned in renovate/pin-dependencies.
  • Both configurations find the same 19 package files, so the shared preset's ignorePaths don't hide anything here.

🤖 Generated with Claude Code