Pull RPM build containers from ghcr.io/simp/simp-<os>-build (fixes fleet-wide RPM build failures)

[silug]

Problem

release_rpms.yml resolves its builder image as:

simp_builder_docker_image: 'docker.io/simpproject/simp_build_${{ github.event.inputs.build_container_os }}:latest'

Docker Hub's simpproject/ namespace has no EL8/9/10 build images. The only relevant ones are:

Image	Last pushed
simpproject/simp_build_centos7	2024-08-09
simpproject/simp_build_centos8	2023-06-26

(plus older centos6 and *_ruby3_1 variants). So no value of build_container_os can select a current container — simpproject/simp_build_el8 does not exist.

Building against those years-old images fails with:

NameError: uninitialized constant JSON::Fragment

JSON::Fragment was added in the json gem 2.9; the stale images ship older. As of 2026-07-28 this is failing in 70 of 71 non-archived repos that have run the workflow, spanning 2026-06-09 → 2026-07-24 — i.e. through the entire 7.0.0/8.0.0 release wave.

Fix

Point at the current containers, which are public and rebuilt weekly:

Image	Tags
ghcr.io/simp/simp-el8-build	latest, 20260428 … 20260720
ghcr.io/simp/simp-el9-build	latest, 20260428 … 20260720
ghcr.io/simp/simp-el10-build	latest, 20260618 … 20260727

Three changes:

1. simp_builder_docker_image → ghcr.io/simp/simp-${os}-build:${tag} — note both the registry host and the image-name shape differ from the old form.
2. New build_container_tag input (default latest) so a dated tag can be pinned for reproducible rebuilds.
3. build_container_os default centos8 → el8 (lowest currently supported EL, so the widest RPM compatibility).

This is already proven in production

pupmod-simp-mockup has carried exactly this configuration for a while and is the only repo with it. The single green release_rpms.yml run anywhere in the org came from it: simp/pupmod-simp-simplib 5.0.3 (build os: el10), dispatched through mockup's workflow via target_repo on 2026-06-22 — signing and release-asset attachment included. This PR ports that working configuration into the baseline so the other 78 repos get it.

Diffed against pupmod-simp-mockup's copy; this PR is the mockup delta minus the runner/action bumps, which #42 already owns (see below).

Relationship to #42

#42 also touches this file, but only bumps runs-on: ubuntu-20.04 → 24.04, actions/github-script@v6 → @v9, and actions/checkout@v5 → @v7. It does not touch the image reference, the input defaults, or add build_container_tag. The two changes are complementary and deliberately kept separate.

⚠️ Merge-order note: my image-line hunk ends around template line 259 and one of #42's github-script@v9 hunks starts around line 259, so whichever merges second may need a trivial context resolution. There is no semantic conflict — keep both sides (the ghcr.io image line and the @v9 bump).

Deliberately not included

• verbose input. mockup un-comments the verbose workflow input, but its build step still hardcodes verbose: 'no' #${{ github.event.inputs.verbose }}, so the input would be exposed while doing nothing. Left as-is here rather than shipping a no-op knob fleet-wide — worth either wiring up properly or leaving commented, as a separate decision.
• The prerelease-tag defect. release_rpms.yml:105's tag regex captures the prerelease counter as a separate optional group from the prerelease word and has no release (-R) component, which is consistent with simp-core#864 / simp-doc#461 (simp-6.6.0-Alpha.el8.noarch.rpm instead of simp-6.6.0-Alpha10-1…). Same file, separate defect — kept out to keep this reviewable.

Verification suggested before syncing to all 78 repos

A release does not have to wait on the sync: because mockup's workflow accepts target_repo + target_repo_token, RPMs can be built and attached for any repo through mockup today. Recommended order:

1. Dispatch with dry_run=yes against one module and confirm the container pulls and the build runs.
2. One real simple module, then one with native/provider bits.
3. Confirm SIMP_CORE_REF_FOR_BUILDING_RPMS (reportedly still 6.5.0-1) is still viable — a real build exercises it immediately.
4. Then sync this template out.

The fleet rollout session (combined per our convention: template change + workflow run in one PR)

This PR also carries the puppetsync session that delivers the change (data/sync/configs/20260731-release-rpms-ghcr.yaml + latest symlink repoints):

• First dynamic-inventory session: repolists/latest.yaml → github-org.yaml (79 repos at last listing; archived/fork/exception handling per Build inventory dynamically from the GitHub API (#55) #74). The generated snapshot (generated-20260731-release-rpms-ghcr.yaml) is what the approve/merge plans consume (repolist=generated-20260731-release-rpms-ghcr).
• Workflow merge scoped to release_rpms.yml (Add optional files scoping to the merge_github_workflows stage #79): the pr_tests.yml template is currently behind the deployed fleet (REFERENCE.md freshness job, Ruby Style job, acceptance matrix — see Reconcile the Ruby Style (rubocop) job in the pr_tests.yml baseline — template and deployed modules have diverged #41/Add a REFERENCE.md freshness check to pr_tests.yml (bundle exec rake validate:strings) #46), so unscoped workflow syncs stay off until the template is reconciled. The config documents this inline.
• Stage plan (verified via list_pipeline_stages): install_gems → checkout → merge_github_workflows (scoped) → git_commit_changes → fork → remote → push → PR.
• Smoke-tested end-to-end against pupmod-simp-aide and pupmod-simp-acpid with dynamic inventory live (details in Add optional files scoping to the merge_github_workflows stage #79): each repo's commit touched exactly this one file (+6/−2, this PR's diff verbatim), all Renovate-managed workflow values preserved, and a second run reported 0 ok / 2 unchanged / 0 failed.

Supersedes #48 (same template commit, rebased onto current main; cherry-picked here so the change and its rollout are reviewed and tested together).

🤖 Generated with Claude Code