Contributing Assets for Existing Ruby Sensu Plugins


It should be possible to quickly add Bonsai assets for most Ruby plugins currently in the Sensu Plugins organization by making use of a Ruby runtime asset to provide the necessary Ruby environment at command runtime. You can learn more about the Ruby runtime assets here

Asset contribution step by step
If you would like to help here is a quick outline on the steps necessary to contribute asset building automation for existing Sensu plugins.

  1. Pick a Sensu Plugin repository without an asset
  2. Fork the official plugin repository
  3. Setup TravisCI GitHub integration to allow access to your fork
  4. configure GITHUB_TOKEN environment variable in TravisCI build environment
  5. Include example .bonsai.yml file in the master branch of your fork
  6. Create a feature branch in your fork in which to add the bonsai build support
  7. Update ruby gemspec to require latest available sensu-plugin as runtime dependency and update CHANGELOG with corresponding Breaking Change comment if needed.
  8. Update travisCI config as per guidance here and update CHANGELOG Unreleased changes section.
  9. Edit branch’s .bonsai.yml as needed
  10. commit branch changes
  11. Create Github release conforming to semver pre-release (ex: 4.0.0-bonsai.0.1 is a pre-release for a 4.0.0 release)
  12. TravisCI should now populate the Github release with binary assets
  13. Optional: Register your forked repository with Bonsai and tag your asset as Experimental.
  14. Test that the Ruby assets work as expected in Sensu Go, if registered with Bonsai, test the provided Bonsai config.
  15. Update the README with Bonsai badge, and asset usage information. Note plugins with handlers and/or mutators may need additional README edits to include information on Sensu Go event model changes.
  16. If everything works, prepare a pull request against the upstream repository. Please provide url for the Bonsai listing you tested. Request review from Github user jspaleta.
  17. Optional: Once PR is merged and upstream asset is available, deprecate your experimental asset and redirect people to the upstream version.

If you run into problems, open a topic in the Asset Discussion subcategory and someone should be able to unstick you. Some plugins may need other adjustments unrelated to the asset changes in order to build cleanly in TravisCI due to a failing test. If you run into one of these situations, file an issue against the upstream repository and assign jspaleta to the issue and I’ll attempt to help sort it out.

1 Like
Using Ruby based assets that require the Ruby runtime asset