Skip to content

Latest commit

 

History

History
75 lines (51 loc) · 3.33 KB

CONTRIBUTING.md

File metadata and controls

75 lines (51 loc) · 3.33 KB

Contributing

You are most welcome to create pull requests and issues to ecChronos. Before creating pull requests it is recommended to first discuss your idea with at least one of the owners of the repository. For keeping track of the history it is recommended that most communication is performed or summarized within pull requests or issues.

Development

Prerequisites

  • Maven
  • JDK11
  • Docker (for test setup)
  • Python

Branches

Target the lowest applicable version of ecChronos when fixing an issue. Bug fixes should be targeted to the lowest maintained version where the bug reside. New features should, in general, be added to the master branch.

Code Style

This project uses the cassandra code style which is based on Sun’s Java coding conventions. Formatting rules for eclipse can be found here.

Provided patches should be contained and should not modify code outside of the scope of the patch. This will make it quicker to perform reviews and merging the pull requests.

Builds

The builds required to merge a pull request are contained within the Github configuration and include tests, code coverage as well as PMD checks.

All checks need to pass before merging a pull request. The current PMD rules are constantly evolving. If you encounter a PMD rule that seems odd or non-relevant feel free to discuss it within an issue or pull request.

Built with

REST API

Whenever there are any changes to the REST API, the OpenAPI specification must be generated. Generation of the OpenAPI specification is done by running the python-integration-tests tests. The generated specification is stored in docs/autogenerated.

ecctool documenation

If changes have been made to ecctool, the documentation must be generated using mvn clean install -P generate-ecctool-doc -DskipUTs. On top of that, if there's any change in the output of ecctool the examples must be updated manually.

Tests

It is recommended to run all tests mvn clean verify -Dprecommit.tests before creating a PR. If applicable, please add test cases to the appropriate test suites. More information can be found on the tests page.

Creating a pull request

  1. Ensure that the pull request is targeted at the minimum possible version based on the type of change.
  2. If you intend to fix an issue, mention the issue number in the text body of the pull requests, i.e. Closes #20.
  3. Add a changelog entry at the top of the current target version when handling an issue. Additionally, the related issue should be mentioned at the end with a - Issue #<nr>.
  4. Before creating a pull request, make sure an issue exists (this does not apply to very small changes). The reason for this is to have the description of the change in the issue itself without needing to describe it in the commit body.
  5. All checks must pass before merging a pull request.
  6. In general at least one project admin should approve the pull request before merging.

Merging

Merging is performed from minimum version towards master. It is the responsibility of the person merging the pull request to make sure it gets merged to master.