[michael-riddle]

Adds the setup-vagrant-libvirt composite action, under .github/actions/, for simp/puppetsync#122: install Vagrant, vagrant-libvirt and libvirt on an Ubuntu runner without failing the job when Launchpad is down.

The pupmod acceptance jobs installed from ppa:evgeni/vagrant alone. On 2026-10-21 Launchpad returned 503 for several hours, every acceptance job failed, and the required All checks status blocked merging. simp/puppetsync#126 switches the pupmod pr_tests.yml templates to this action and adds a vagrant_package_cache.yml workflow that warms its cache from each repo's default branch.

Behavior

The action tries, in order:

1. The Actions cache: the PPA's packages, restored from the newest key for the runner's Ubuntu series and architecture. No request goes to Launchpad.
2. The PPA: add-apt-repository, a refresh of the PPA's index alone with --error-on=any, then the install. Each step is retried three times, 30s and then 60s apart. Other apt-get update calls are plain, so a flaky third-party source on the runner image doesn't fail the job.
3. HashiCorp: vagrant pinned to vagrant-version (2.4.9-1), and vagrant plugin install vagrant-libvirt pinned to vagrant-libvirt-version (0.12.2), with a ::warning:: that this is BSL-licensed Vagrant. On a series the PPA doesn't publish for (ppa-series, default noble), the action goes straight here with a ::notice::. ubuntu-latest is moving to 26.04, which the PPA doesn't cover.

When the PPA path fails, its sources file is deleted directly, because add-apt-repository -r can itself need Launchpad.

cache-only

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. With cache-only: 'true', the action is meant for a default-branch workflow (push and schedule). It works as follows:

• It runs apt-get install --print-uris vagrant vagrant-libvirt and keeps every package the PPA would provide, so a dependency the PPA ships is cached too.
• It derives the key from their file names. Nothing is pinned, so a new PPA build gets a new key rather than breaking the download, and installs restore the newest key by prefix.
• It restores the key if it exists, which also keeps GitHub from evicting it after seven days unused. Otherwise it downloads the packages with apt-get download, which checks them against the PPA's signed index, and saves them.
• It fails if the PPA can't be reached after the retries, so a scheduled run shows the outage.

Testing

• shellcheck and actionlint pass. The cache path (resolve, download, then install with the PPA removed) was also run in an ubuntu:24.04 container.
• This PR's CI (ci.yml) runs the action on real runners: cache-only on ubuntu-24.04 and ubuntu-latest, and five install cases covering the cache, the PPA and HashiCorp, with Launchpad reachable and blocked (via /etc/hosts).
• The same matrix passed with the action vendored into a fork of pupmod-simp-aide: run 41525307284.
• The cross-ref case also passed. The cache workflow ran on a base branch (run 41523918417). Then a PR against that base, with Launchpad blocked, restored the cache and passed the full aide acceptance suite on almalinux9 and almalinux10 (run 41524042130).

Which runner

The cache and the PPA only apply on noble (ubuntu-24.04), the one series the PPA publishes for. ubuntu-latest now resolves to ubuntu-26.04, so jobs on it, including the pupmod acceptance jobs, install HashiCorp's Vagrant directly with a notice and never contact Launchpad. The cache and PPA paths are a hedge for jobs on ubuntu-24.04. The README says so.

Where it lives

This is the first composite action in this repo. The README said single actions go in their own simp/github-action-* repos. It now lists composite actions under "What belongs here", so there is one repo to manage instead of one per action, and adds an "Actions" table. Callers pin a tag as with the workflows: uses: simp/gha-workflows/.github/actions/setup-vagrant-libvirt@v1.1.0.

CI gains shellcheck for the actions' scripts and the action test jobs below. The tests depend on Launchpad, so they only run when the action or ci.yml changes; a changes job decides, and All checks counts a skipped job as passing. A Launchpad outage then can't block an unrelated PR here.

After merge

Tag v1.1.0 (a new action is a minor release); simp/puppetsync#126 pins to it.

🤖 Generated with Claude Code

[silug]

Overall the action looks solid, and the PR's CI exercises every path on real runners. Keeping it in this repo, rather than a new github-action-* repo, seems right to me: it has the same consumers, the same tag-pinning and Renovate flow, and the same branch protection.

Two things to fix: (1) ubuntu-latest is already 26.04, so the fleet's acceptance jobs skip the PPA and cache entirely, and (2) the action's test jobs now gate every PR to this repo on Launchpad being up. The other comments are mostly README prose.