Add GitHub Actions CI page and link DevKit from Hello OpenVox

[miharp]

Closes #464

What this adds

New page: devkit/ci.md ("Module CI with GitHub Actions"), in the sidebar as "GitHub Actions CI" between "Consistent Style" and "Using VoxBox in CI".

• What gha-puppet's basic.yml expects to find in the module before it can run: a Gemfile (test group with voxpupuli-test, puppet_metadata, and openvox reading OPENVOX_GEM_VERSION), a Rakefile, and a metadata.json with a requirements entry. jig new module produces all three; jig convert (2.4.0 or later) produces them for an existing module too, creating or repairing metadata.json as needed (Fixing bad behavior on inconsistent modules voxpupuli/jig#92).
• The ten-line ci.yml that calls the reusable workflow, a table of the three jobs it produces and which rake tasks each runs, and a table of the with: inputs (taken from basic.yml on the v4 tag rather than the README).
• How to reproduce the same checks locally, and how to switch to beaker.yml for acceptance tests (links to the existing guide).
• A lighter parser-validate-and-lint-only workflow for repositories that don't want the full toolchain, with a note on what it can't catch, and that neither workflow applies the manifest.
• Troubleshooting entries for the failures a module without those files produces (Could not locate Gemfile, unit → skipped, metadata2gha errors).

Getting Started page: a third Next Steps bullet pointing to the Developer Tooling section and the new CI page. The Hello OpenVox walkthrough previously had no path to the DevKit docs at all, which is how the question in #464 came up.

Verification

• markdownlint-cli2 clean on both touched files.
• bundle exec jekyll build succeeds; the page renders under ecosystem/latest/devkit/ci.html, the sidebar entry appears, and every internal link and anchor on the new page resolves to an existing page.
• The Gemfile and Rakefile examples mirror jig's current module template and puppet-nftables, so they match what the tooling generates today.
• The jig convert behavior was checked with the jig 2.4.0 binary on a Modulefile-era module and on a module with no metadata at all: both runs created metadata.json (with an openvox requirements entry) and jig.toml, then wrote the Gemfile, Rakefile, and spec helper.

Assisted by Claude.

[fsteinel]

maybe out of scope:
what is jig convert is there something to read for me as a ruby and openvox beginner
EDIT:
ah, found and usinǵ https://github.com/voxpupuli/jig/releases#release-v2.3.1

[miharp]

Converting this to a draft for now. voxpupuli/jig#92 makes jig convert create metadata.json when it's missing (pre-filled from a Modulefile if there is one) and repair an incomplete one, which removes the "write metadata.json first, then run jig convert" step this page currently documents. I'll wait for that to merge and land in a Jig release, then update the prerequisites section here to match before marking this ready again.

[bastelfreak]

I'm a bit torn here. This is already documented in the README.md for gha-puppet: https://github.com/voxpupuli/gha-puppet . Duplicating the information will always lead to issues, but it would be nice to have it on the website but also in gha-puppet. could we maybe embed the README.md in our docs website? or move the setup instructions into a new file? or move it out of gha-puppet and point to the docs website?

I don't know which approach is the best.

[miharp]

The README is actually behind the workflow here: it still shows the puppet gem with PUPPET_GEM_VERSION, puppetlabs_spec_helper, voxpupuli-test 7.x, and @v1, while v4 sets OPENVOX_GEM_VERSION and jig's template generates the versions on this page. So there isn't a current copy to embed yet.

I'd go with your third option: I can open a PR on gha-puppet that swaps the README's Gemfile/Rakefile sections for a pointer to jig new module / jig convert and this page, and leaves the workflow inputs, subdirectory, and release docs where they are. Does that work for you?