Skip to content

RELEASE.md

Latest commit

 

History

History
28 lines (22 loc) · 1.86 KB

RELEASE.md

File metadata and controls

28 lines (22 loc) · 1.86 KB

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)
    • 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_webhooks/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 should get triggered and should build the gem and push it to rubygems.org.

Once the new version lands in rubygems, consider filing a packaging PR on foreman-packaging or triggering it via automation with:

gh workflow run bump_packages.yml \
  --repo theforeman/foreman-packaging \
  --raw-field package=hammer_cli_foreman_webhooks

Note on permissions

The steps outlined above require write access to the repository. This is generally controlled by membership in the @webhooks 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.