[michael-riddle]

Fixes #122.

The templates pin simp/gha-workflows v1.1.0 (simp/gha-workflows#18).

The pupmod acceptance jobs installed vagrant and vagrant-libvirt from ppa:evgeni/vagrant alone, so a Launchpad outage failed every acceptance job and, through the required All checks status, blocked merging. This keeps the PPA as the primary source and makes the setup survive its outages.

Workflow templates

In both pr_tests.yml templates, "Setup libvirt for Vagrant" becomes one step:

      - name: Setup libvirt for Vagrant
        uses: simp/gha-workflows/.github/actions/setup-vagrant-libvirt@v1.1.0

The setup-vagrant-libvirt action in simp/gha-workflows installs from the Actions cache, then the PPA (with retries), then HashiCorp's apt repository plus vagrant plugin install vagrant-libvirt, with a warning that the last is BSL-licensed. simp/gha-workflows#18 has the details. Because the logic lives in gha-workflows, a later fix is a tag bump that Renovate proposes per repo, not a fleet sync. Any other repo with a Vagrant/libvirt acceptance job, including Ruby projects, can use the same step.

A pull request can only restore caches saved from its own ref, its base branch or the default branch, so caches saved by pull requests don't help other PRs. The new vagrant_package_cache.yml template runs the action with cache-only: 'true' from the default branch. It runs twice a week, which also keeps the cache from being evicted after seven days without use, and on a push to the default branch that changes the workflow file, which seeds the cache when it lands. Other pushes don't run it, so merges during a Launchpad outage don't each get a failed run. It runs on ubuntu-24.04 because the PPA only publishes for noble, so it only helps acceptance jobs on ubuntu-24.04; see the next section.

Only modules whose acceptance job uses Vagrant get this workflow, so it isn't in the pupmod baseline's present_action_files. This sync adds it with ensure_files, and later merge_github_workflows runs refresh it wherever it exists.

Ubuntu 26.04 runners

ubuntu-latest is moving to 26.04 (resolute): the 2026-10-27 auditd acceptance run was on ubuntu-24.04, and test runs on 2026-11-02 got ubuntu-26.04. The PPA has no resolute builds, so the current step fails there. On 26.04 the action goes straight to HashiCorp's Vagrant 2.4.9 with a notice. Pinning the acceptance job to runs-on: ubuntu-24.04 would keep the MPL build until GitHub retires that image. runs-on is part of each repo's preserved acceptance block, so that would be a separate change.

Syncing to the fleet

jobs.acceptance is repo-owned during syncs (preserve_blocks), so a template change to it can't reach the repositories. merge_gha_workflows gains a template_steps option for steps the template stays authoritative for inside preserved blocks:

• Each of a preserved job's steps with a listed name is replaced in place by the template's step of that name, reindented to match.
• A listed step the job lacks goes in next to its template neighbours, so the repo's own steps keep their positions.
• Comments and blank lines before the next step stay with it.
• A job with none of the named steps is left alone.
• A listed name the template's job lacks is an error, not a deletion. So is a name more than one step in a job has, since replacing both would drop what told them apart (an if:, say).
• preserve_keys still applies to grafted steps, so a repo whose Renovate has bumped the action past the template's tag keeps its tag on the next sync. A later template change that needs a new tag together with new inputs reaches each repo as the inputs at sync time and the tag through Renovate.

The plan passes puppetsync.plans.sync.merge_github_workflows.template_steps through.

The new 20261102-vagrant-ppa-fallback config uses it, together with ensure_files for vagrant_package_cache.yml. ensure_files adds the file to every repo in the session, so the config is meant for the new pupmods_vagrant_acceptance repolist: the 38 pupmods whose acceptance job uses Vagrant. That is 36 from pupmods.yaml plus pupmod-simp-rngd and pupmod-simp-simp_authselect, which aren't in it. Both latest.yaml symlinks point at them. Run against the current pr_tests.yml of those 38 and of every repository in pupmods.yaml:

• the 38 Vagrant repositories get exactly the new step (a 6-line change), with their matrices, suites and other steps unchanged;
• the 25 podman-based repositories and the 21 without an acceptance job are unchanged;
• a second pass changes nothing.

After this merges, run bolt plan run puppetsync config=20261102-vagrant-ppa-fallback repolist=pupmods_vagrant_acceptance to open the downstream PRs.

Testing

• rspec (266 examples) and the BoltSpec plan specs (32) pass. New specs cover in-place replacement, steps kept between named steps, steps the job lacks, comments belonging to the next step, commented-out keys belonging to the step, reindentation, jobs without the named steps, the errors for a name the template lacks and for a name two steps share, the repo's tag surviving a later sync, idempotency and the plan passthrough.
• End to end on a fork of pupmod-simp-aide, with the merged workflows and the action vendored as a local action:
  • Cache workflow on a base branch: resolved the PPA's two packages and saved them.
  • PR Tests on a PR against that base, with Launchpad blocked: both acceptance legs restored the base branch's cache, installed with no Launchpad access, and passed (50 examples, 0 failures each). Every other PR Tests job passed too.
  • The action's CI matrix: cache-only on 24.04 (saved) and 26.04 (nothing to cache), and installs from cache (Launchpad reachable and blocked), ppa, and hashicorp (Launchpad blocked on 24.04, and on 26.04).

🤖 Generated with Claude Code

[michael-riddle]

The setup action moved out of its own repo and into simp/gha-workflows (simp/gha-workflows#18), so there is one repo to manage. The templates now use simp/gha-workflows/.github/actions/setup-vagrant-libvirt@v1.1.0. The review replies above that mention simp/github-action-setup-vagrant-libvirt refer to the same action, unchanged; this PR merges after gha-workflows#18 is merged and tagged v1.1.0.

[hcaballero2]

I ran the task from this branch against the live pr_tests.yml of every repo with the PPA step. All 38 get exactly the same 6-line swap to the action, and a second pass changes nothing. It's compatible with gha-workflows#18 / v1.1.0. A few things for you to decide, since you have the most context:

1. Two repos missing from the repolist

pupmod-simp-rngd (default branch main) and pupmod-simp-simp_authselect have the same "Setup libvirt for Vagrant" step but aren't in pupmods_vagrant_acceptance.yaml. pupmods.yaml predates rngd and never had simp_authselect. Both merge cleanly, like the other 36. Add them here, or handle them separately?

2. The cache workflow while acceptance runs on ubuntu-latest

All 36 (38) acceptance jobs run on ubuntu-latest, which now resolves to 26.04. There the action goes straight to HashiCorp and never restores the noble cache that vagrant_package_cache.yml saves. Meanwhile that workflow:

• runs on every push to the default branch, and by design fails while Launchpad is down, so each merge during an outage gets a failed run;
• isn't in present_action_files, so later baseline runs won't deliver it, despite its "maintained with puppetsync" notice.

Options I see:

• a. Keep it as a hedge for a future pin to ubuntu-24.04.
• b. Drop it, and ensure_files, from this sync, and add it if acceptance is ever pinned to 24.04. No current job reads the cache, so nothing changes for them.
• c. Pin acceptance to ubuntu-24.04 so the cache and the PPA are actually used. runs-on is inside the preserved block, so that would need its own change.

3. template_steps vs preserve_keys on a later sync

preserve_keys runs after the graft, so the repo's existing tag on the grafted step wins. I tested both directions:

• A repo Renovate bumped to @v1.2.0 keeps it when the template still says @v1.1.0. That's good, and it's what letting the template win would break.
• A template that moves to @v2.0.0 and adds a with: input gets the new input paired with the repo's old tag.

Neither matters for this sync. Is the current behaviour what you intend? If so, a line in the task header saying so would help the next person who uses template_steps.

Minor, and no current repo hits them: two steps with the same listed name both get replaced (the repo's if: is lost), and trailing commented-out keys at the step's key column stay behind under the new step.

[michael-riddle]

@hcaballero2 thanks for running it against the live fleet. Addressed in bd824a8:

1. Missing repos: added pupmod-simp-rngd (branch main) and pupmod-simp-simp_authselect to pupmods_vagrant_acceptance.yaml. I re-ran the task against the live pr_tests.yml of all 38. Each gets only the 6-line swap, and a second pass changes nothing.

2. The cache workflow: we're keeping it (option a). It's a hedge for acceptance jobs on ubuntu-24.04, whether that's a pin later or a repo that already uses it. Your two concrete problems are fixed:

• On push it now runs only when vagrant_package_cache.yml itself changes (paths:). It still seeds the cache when the file lands, but merges during a Launchpad outage no longer each get a failed run. The twice-weekly schedule is unchanged.
• It stays out of present_action_files on purpose: that list applies to every pupmod, podman and no-acceptance ones included. This session delivers it with ensure_files, and later merge_github_workflows runs refresh it wherever it exists, so the "maintained with puppetsync" notice holds. The file's header now says so.

3. template_steps vs preserve_keys: yes, that's intended. A repo Renovate has bumped shouldn't be rolled back. The task header now documents it: a template change that needs a new tag and new inputs together reaches each repo as the inputs at sync time and the tag through that repo's Renovate PR. There's a spec for the bumped tag surviving a sync.

Minor:

• Two steps sharing a listed name now fail the task (template_steps name more than one step in a job: ...) instead of both being replaced, so a repo's if: can't be lost silently.
• Commented-out keys at the step's key column now stay with the step and are replaced with it. Comments outdented to the - column still belong to the next step.

Both have specs. rspec (266) and the plan specs (32) pass, and the PR description is updated.

All requested changes are addressed in da7ace8, 3836513 and bd824a8, and every review thread is resolved. The current head is approved by hcaballero2. Dismissing so the PR can merge while silug is unavailable.