#Contributing

Contributions, issues and pull requests are welcome. Please visit the GitHub home for this project.

#License

This code is under the Eclipse v2 license

#Source

JRuby Scripting openHAB is hosted on GitHub.

#Development Environment Setup

The development process has been tested on MacOS, and Ubuntu. Other operating systems may work.

  1. Install Ruby 2.6.8 and JRuby 9.3.8.0 (or later)
  2. Fork the repo and clone it
  3. Install bundler
  4. Run bundler install from inside of the repo directory
  5. To avoid conflicts, the openHAB development instance can use custom ports by defining these environment variables:
    • OPENHAB_HTTP_PORT
    • OPENHAB_HTTPS_PORT
    • OPENHAB_SSH_PORT
    • OPENHAB_LSP_PORT
  6. Run bundle exec rake openhab:setup from inside of the repo directory. This will download a copy of openHAB local in your development environment, start it and prepare it for JRuby openHAB Scripting Development
  7. Install pre-commit and then run pre-commit install if you would like to install a git pre-commit hook to automatically run rubocop.

#Code Documentation

Code documentation is written in Yard and the current documentation for this project is available on GitHub pages.

#Development Process

  1. Create a branch for your contribution.
  2. Write your tests the project uses Behavior Driven Development with RSpec. The spec directory has many examples. Feel free ask in your PR if you need help.
  3. Write your code.
  4. Verify your tests now pass by running bin/rspec spec/<your spec file>_spec.rb. This requires JRuby.
  5. Update the documentation, run bin/yardoc to view the rendered documentation locally
  6. Lint your code with bundle exec rake lint:rubocop and ensure you have not created any Rubocop violations.
  7. Submit your PR(s)!

If you get stuck or need help along the way, please open an issue.

#Release Process

A release is triggered manually using the GitHub Release Workflow which will perform these steps:

  1. Update the changelog automatically.
    • It will collect all issues and pull requests labelled bug, enhancements or breaking that have been closed / merged since the last release.
    • Issues/PRs without labels won't be included in the changelog.
    • The issue/PR titles will be used as the log entry. They can be edited prior to running the release action.
    • An optional release summary can be added by creating and closing an issue labelled release-summary. The content of the issue's first post will be inserted under the version number heading.
  2. Bump the library's version number.
  3. Commit the updated changelog and version number to the github repository.
  4. Create a new version tag and GitHub release entry.
  5. Publish the new gem version to RubyGems.