ceph-csi/docs/development-guide.md

Development Guide

New to Go

Ceph-csi is written in Go and if you are new to the language, it is highly encouraged to:

• Take the A Tour of Go course.
• Set up Go development environment on your machine.
• Read Effective Go for best practices.

Development Workflow

Workspace and repository setup

• Download Go (>=1.11.x) and install it on your system.
• Setup the GOPATH environment.
• Run $ go get -d github.com/ceph/ceph-csi This will just download the source and not build it. The downloaded source will be at $GOPATH/src/github.com/ceph/ceph-csi
• Fork the ceph-csi repo on Github.
• Add your fork as a git remote: $ git remote add fork https://github.com/<your-github-username>/ceph-csi

Editors: Our favorite editor is vim with the vim-go plugin, but there are many others like vscode

Building Ceph-CSI

To build ceph-csi run: $ make

The built binary will be present under _output/ directory.

Code contribution workflow

ceph-csi repository currently follows GitHub's [Fork & Pull] (https://help.github.com/articles/about-pull-requests/) workflow for code contributions.

Please read the coding guidelines document before submitting a PR.

Here is a short guide on how to work on a new patch. In this example, we will work on a patch called hellopatch:

• $ git checkout master
• $ git pull
• $ git checkout -b hellopatch

Do your work here and commit.

Run the test suite, which includes linting checks, static code check, and unit tests:

$ make test

You will need to provide unit tests and functional tests for your changes wherever applicable.

Once you are ready to push, you will type the following:

$ git push fork hellopatch

Creating A Pull Request: When you are satisfied with your changes, you will then need to go to your repo in GitHub.com and create a pull request for your branch. Automated tests will be run against the pull request. Your pull request will be reviewed and merged.

If you are planning on making a large set of changes or a major architectural change it is often desirable to first build a consensus in an issue discussion and/or create an initial design doc PR. Once the design has been agreed upon one or more PRs implementing the plan can be made.

Review Process: Once your PR has been submitted for review the following critieria will need to be met before it will be merged:

• Each PR needs reviews accepting the change from at least two developers
• for merging
  • It is common to request reviews from those reviewers automatically suggested
  • by github
• Each PR needs to have been open for at least 24 working hours to allow for
• community feedback
  • The 24 working hours counts hours occuring Mon-Fri in the local timezone
  • of the submitter
• Each PR must be fully updated to master and tests must have passed

When the criteria are met, a project maintainer can merge your changes into the project's master branch.