Skip to content

Latest commit

 

History

History
72 lines (47 loc) · 3.94 KB

CONTRIBUTING.md

File metadata and controls

72 lines (47 loc) · 3.94 KB

Contributing to Scylla Operator

Initial Setup

Fork the repository

Follow GitHub's official documentation on forking a repository.

Development

To add a feature or to make a bug fix, you will need to create a branch in your fork and then submit a pull request (PR) from the branch. A subset of useful commands:

  • make build - build project binaries
  • make test-unit - run unit tests
  • make update - run all code generators
  • make verify - verify if all autogenerated changes are generated.

Check make help for more.

Coding convention

Follow these guidelines for writing and structuring your code:

In cases where the existing code doesn't fully follow these conventions, try to be consistent with what's already there. Make sure to familiarize yourself with these resources before making changes.

Enhancement proposals

For significant features or API changes, you might be required to prepare an enhancement proposal beforehand, as these usually involve broader discussions. If unsure, please consult the maintainers of the project to learn if your contribution falls into these categories before you start working on the implementation.
For further details, see Enhancement Proposals directory.

Submitting a Pull Request

Once you have implemented the feature or bug fix in your branch, open a PR to the upstream repository. Before doing so, ensure the following:

  • Unit tests are included.
  • End-to-end tests are passing.
  • Your commit history is clean.

Commit History

To maintain a clean commit history, aim for a minimal number of logical commits. Typically, this means a single commit that contains all the changes, with a separate commit for autogenerated parts.

Commits and PRs

The subject line of your commit message and the PR title should summarize the change in one clear sentence that would be meaningful to a user of the Operator. The sentence should be written in the imperative, i.e. written as if giving a command or instruction, e.g. "Add support for XYZ". A properly formed Git commit subject line should always be able to complete the sentence "If applied, this commit will...", e.g. "If applied, this commit will Add support for XYZ". Changelog entries are verbatim PR titles, so make them concise yet informative.

Further details should be added after a blank line. Explain why the change was necessary, not just what was changed. In the general case, extensive descriptions are well-received. Comparing the behavior before and after the change is especially helpful. Write the message with the mindset that you’ll need to revisit the code in the future. If your PR fixes an issue, include "Resolves #1234" in the description, replacing "1234" with the issue number.

**Description of your changes:**
Add new XYZ field to ScyllaCluster CRD.
The new field allows for configuration of ZYX feature of ScyllaDB.
<more details>
API change was discussed in the following enhancement: <link>.

**Which issue is resolved by this Pull Request:**
Resolves #1234

Code review

Refer to The Standard of Code Review for best practices when conducting peer reviews or responding to feedback.

Submitting

After addressing the review feedback, squash your changes into the original commits. Avoid adding new commits. Your PR should always be in a mergeable state.