그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그 그

  3 minute read  

Raising a Pull Request

We welcome active contributions from the community. This document details out the things-to-be-done in order for us to consider a PR for review. Contributors should follow the guidelines mentioned in this document to minimize the time it takes to get the PR reviewed.

00-Prerequisites

In order to make code contributions you must setup your development environment. Follow the Prepare Dev Environment Guide for detailed instructions.

01-Raise an Issue

For every pull-request, it is mandatory to raise an Issue which should describe the problem in detail. We have created a few categories, each having its own dedicated template.

03-Prepare Code Changes

  • It is not recommended to create a branch on the main repository for raising pull-requests. Instead you must fork the etcd-druid repository and create a branch in the fork. You can follow the detailed instructions on how to fork a repository and set it up for contributions.

  • Ensure that you follow the coding guidelines while introducing new code.

  • If you are making changes to the API then please read Changing-API documentation.

  • If you are introducing new go mod dependencies then please read Dependency Management documentation.

  • If you are introducing a new Etcd cluster component then please read Add new Cluster Component documentation.

  • For guidance on testing, follow the detailed instructions here.

  • Before you submit your PR, please ensure that the following is done:

    • Run make check which will do the following:

      • Runs make format - this target will ensure a common formatting of the code and ordering of imports across all source files.
      • Runs make manifests - this target will re-generate manifests if there are any changes in the API.
      • Only when the above targets have run without errorrs, then make check will be run linters against the code. The rules for the linter are configured here.

    • Ensure that all the tests pass by running the following make targets:

      • make test-unit - this target will run all unit tests.
      • make test-integration - this target will run all integration tests (controller level tests) using envtest framework.
      • make ci-e2e-kind or any of its variants - these targets will run etcd-druid e2e tests.

      !!! warning Please ensure that after introduction of new code the code coverage does not reduce. An increase in code coverage is always welcome.

  • If you add new features, make sure that you create relevant documentation under /docs.

04-Raise a pull request

  • Create Work In Progress [WIP] pull requests only if you need a clarification or an explicit review before you can continue your work item.
  • Ensure that you have rebased your fork’s development branch with upstream main/master branch.
  • Squash all commits into a minimal number of commits.
  • Fill in the PR template with appropriate details and provide the link to the Issue for which a PR has been raised.
  • If your patch is not getting reviewed, or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment.

05-Post review

  • If a reviewer requires you to change your commit(s), please test the changes again.
  • Amend the affected commit(s) and force push onto your branch.
  • Set respective comments in your GitHub review as resolved.
  • Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.

06-Merging a pull request

  • Merge can only be done if the PR has approvals from atleast 2 reviewers.
  • Add an appropriate release note detailing what is introduced as part of this PR.
  • Before merging the PR, ensure that you squash and then merge.