Fixes #38980 - Add automatic release process

.github/workflows/release.yml

@@ -0,0 +1,20 @@
+name: Release
+
+on:
+  push:
+    # Pattern matched against refs/tags
+    tags:
+      - '**'
+
+jobs:
+  release:
+    name: Release gem
+    runs-on: ubuntu-latest
+    environment: release
+    if: github.repository_owner == 'theforeman'
+
+    permissions:
+      id-token: write
+
+    steps:
+      - uses: voxpupuli/ruby-release@v0

README.md

@@ -71,4 +71,6 @@ Extension module hammer_cli_foreman_openscap (version) loaded
 If you see no errors, you should be good to go.
 
 
+## Release
 
+Please refer to [RELEASE.md](RELEASE.md)

RELEASE.md

@@ -0,0 +1,28 @@
+# Releasing the plugin
+
+To release the plugin the following steps are required:
+1. Checkout the branch you want to make the release from
+2. Determine what the next version should be
+   - We try to follow [semantic versioning (semver)](https://semver.org)
+   - Usually we don't increase the major version for hammer plugins, only minor if it requires a newer corresponding Foreman plugin. Most of the time you bump patch version.
+   - For the rest we follow semver
+3. Bump the version in the version file - `lib/hammer_cli_foreman_openscap/version.rb`
+4. Make a commit "Bump version to $version"
+5. Place a version tag on the commit with `git tag v$version`
+   - Ideally the tag should be signed.
+6. Push the commit and the tag to the upstream repository with `git push --follow-tags`
+
+When the tag is pushed to git, [the release workflow](.github/workflows/release.yml) should get triggered and should build the gem and push it to [rubygems.org](https://rubygems.org/gems/hammer_cli_foreman_openscap).
+
+Once the new version lands in rubygems, consider filing a packaging PR on [foreman-packaging](https://github.com/theforeman/foreman-packaging) or triggering it via automation with:
+```shell
+gh workflow run bump_packages.yml \
+  --repo theforeman/foreman-packaging \
+  --raw-field package=hammer_cli_foreman_openscap
+```
+
+### Note on permissions
+
+The steps outlined above require write access to the repository. This is generally controlled by membership in the [@openscap](https://github.com/orgs/theforeman/teams/openscap) team. If needed, steps 1-4 can be done even without permissions. In that case, skip step 5, push the changes to your own fork and send us a pull request, asking for a maintainer to perform step 5.
+
+Similar situation applies to the packaging workflow. It can be triggered (and resulting PRs merged) by members of the team. PRs can also be prepared by hand and sent by anyone.