ci: add release-please automation and cut 1.0.0

[tas50]

Why

Releases here are entirely manual, and it shows: RubyGems' latest kitchen-cloudstack is 0.24.0 — the version that raises NameError: uninitialized constant Kitchen::Driver::SSHBase on load. The 1.0.0 that fixes it (#46) is sitting on main, unreleased and invisible to every user.

What this does

Adopts the same release-please setup the other test-kitchen drivers use. Merges to main open a release PR; merging that PR tags the release and publishes to RubyGems and GitHub Packages.

Built on @Stromweld's earlier work in #36, with the action versions brought up to what kitchen-ec2 currently runs — release-please-action@v5 and checkout@v7 rather than v4/v4.

File	Purpose
.github/workflows/publish.yml	release-please + publish, mirroring kitchen-ec2
release-please-config.json	release-type: ruby, version file lib/kitchen/driver/cloudstack_version.rb
.release-please-manifest.json	starts at 0.24.0, the last actually-published version
.github/CODEOWNERS	@test-kitchen/maintainers

How 1.0.0 gets cut

The repo has no git tags, and #44/#46 weren't Conventional Commits, so release-please has nothing to infer a version from. The commit on this branch therefore carries a Release-As: 1.0.0 footer, which forces the next release to 1.0.0 — matching the version already committed in cloudstack_version.rb and CHANGELOG.md.

Because this repo squash-merges with squash_merge_commit_message: COMMIT_MESSAGES, that footer survives into main, and the workflow added here runs on the same push.

Important

Please keep the Release-As: 1.0.0 line in the squash commit message when merging. Without it release-please won't cut a release.

Note

release-please regenerates CHANGELOG.md, so the release PR it opens may duplicate or reformat the hand-written 1.0.0 notes from #46. That release PR is editable — worth tidying the changelog there before merging it.

Verified

• yamllint -c .yamllint . — exit 0 across the repo
• All three required secrets (PORTER_GITHUB_TOKEN, OWNER, RUBYGEMS_API_KEY) confirmed present as org-level secrets available to this repo
• Config shape diffed against test-kitchen/kitchen-ec2, which is on release-please today

Closes #36

🤖 Generated with Claude Code

[tas50]

Updated after a security review of the workflow. Two hardening changes from the version kitchen-ec2 runs today, both about not handing publishing credentials to code that can change underneath us:

Pinned actions to commit SHAs. The two actionshub publish actions were referenced as @main — a mutable branch that receives RUBYGEMS_API_KEY. Anyone able to push to those branches could change what runs with this project's RubyGems publishing key at any time. All four actions are now pinned to SHAs, with the version in a trailing comment so Renovate can keep them current.

Added an explicit permissions: block. This repo's default_workflow_permissions is write, so without one the publish steps would run with a broadly scoped GITHUB_TOKEN. It's now contents: read / packages: write at the top level, with the job narrowed to what release-please actually needs.

Verified yamllint is clean under --strict, and that no mutable refs remain.

Worth noting the same @main references exist in kitchen-ec2, kitchen-vagrant and test-kitchen — probably worth the same treatment there, but out of scope for this PR.