Reconcile the Ruby Style (rubocop) job in the pr_tests.yml baseline — template and deployed modules have diverged

[silug]

Problem

The Ruby Style (rubocop) job in the pupmod pr_tests.yml baseline is in an inconsistent state between the template and what is actually deployed to the modules.

Template — modules/profile/files/pupmod/_github/workflows/pr_tests.yml:

  ruby-style:
    if: false # TODO Modules will need: rubocop in Gemfile, .rubocop.yml
    name: 'Ruby Style (experimental)'
    runs-on: ubuntu-latest
    continue-on-error: true

i.e. the job is disabled (if: false), marked experimental, and set to continue-on-error: true, pending modules having rubocop wired up.

Deployed modules — the job has drifted: it runs (no if: false, name 'Ruby Style') but still carries continue-on-error: true, so rubocop failures are silently ignored in CI. This is currently the case in ~70 of 71 non-archived pupmod-simp-* repos.

Why now

The round-2 OpenVox 9 / Ruby 4.0 migration standardized the rubocop stack across all modules (rubocop/-rake/-rspec now come via voxpupuli-test through simp-rake-helpers ~> 6.0, and every module has a .rubocop.yml). So the template's TODO precondition ("Modules will need: rubocop in Gemfile, .rubocop.yml") is now satisfied — rubocop can be a real, enforced check.

Ask

Decide the intended policy and reconcile the baseline so it matches, then resync:

• Drop if: false and the (experimental) name, and remove continue-on-error: true so rubocop actually gates CI; or deliberately keep it advisory — but make the template and the deployed modules agree either way.

Related

Real rubocop failures currently masked by continue-on-error (to be fixed alongside enforcement):

• CI ignores rubocop failures (Ruby Style job is continue-on-error) and rubocop is currently failing pupmod-simp-auditd#265
• CI ignores rubocop failures (Ruby Style job is continue-on-error) and rubocop is currently failing pupmod-simp-deferred_resources#94
• CI ignores rubocop failures (Ruby Style job is continue-on-error) and rubocop is currently failing pupmod-simp-iptables#167
• CI ignores rubocop failures (Ruby Style job is continue-on-error) and rubocop is currently failing pupmod-simp-site#62
• CI ignores rubocop failures (Ruby Style job is continue-on-error) and rubocop is currently failing pupmod-simp-haveged#84

Surfaced during the round-2 OpenVox 9 / Ruby 4.0 migration.

[silug]

Draft PR #42 reconciles the pupmod baseline with the deployed openvox9-ruby4-preview state. It keeps continue-on-error: true on the Ruby Style job to match reality — removing it (this issue's scope) can ride the next template pass now that rubocop is clean fleet-wide.

[silug]

Folding in findings from a 2026-07-27 org-wide survey (originally filed as #46's sibling #45, now closed as a duplicate of this issue — this issue is broader, since it also covers the template's if: false / (experimental) divergence that the survey missed).

⚠️ There are two continue-on-error uses in this workflow — only one is the bug

This is the trap worth recording before any sweep runs:

Occurrence	Repos	Action
ruby-style: job → continue-on-error: true	78	remove — the subject of this issue
parallel_spec step → continue-on-error: ${{matrix.puppet.experimental}}	75	keep — gates the Ruby 4 / OpenVox 9 preview matrix entry

74 repos have both. A sweep matching on continue-on-error alone would silently remove the OpenVox 9 preview gate along with the rubocop one. Match only the literal job-level continue-on-error: true.

Refined scope: 78 repos, not ~70

Counted by parsing pr_tests.yml on master across all non-archived org repos: 82 have a pr_tests.yml, 78 carry the unconditional continue-on-error: true. All 78 are SIMP-maintained (this includes pkg-r10k and puppet-gpasswd, which are easy to mistake for third-party).

Evidence that enforcement should hold — 0 of 78 have a .rubocop_todo.yml

This supports the 2026-07-10 note above that rubocop is clean fleet-wide. 37 repos in the org do have a .rubocop_todo.yml, but every one is a vendored/forked module (augeasproviders_*, pupmod-voxpupuli-*, inspec_tools, binford2k-node_encrypt) and none of them uses this pr_tests.yml baseline — they were not in the 82.

Caveat: absence of a todo file is not proof of zero offenses, only that nobody parked any. Worth landing on one pilot module and confirming Ruby Style goes green before the full resync.

The 5 related per-module issues are now closed

The issues listed under Related above were closed as not_planned, consolidated into this line of work rather than fixed per-module (they would have been reverted by the next sync anyway): auditd#265, deferred_resources#94, iptables#167, site#62, haveged#84.