doc: add list of valid components to the development guide

The commitlint CI job uses the configuration from .commitlintrc.yaml
which contains the different components that Ceph-CSI uses. A short
description of each component has been added, so that contributors
understand what component to mention in the prefix of the subject in
commit messages.

Signed-off-by: Niels de Vos <ndevos@redhat.com>
This commit is contained in:
Niels de Vos 2020-05-11 14:51:27 +02:00 committed by mergify[bot]
parent 3be9d99573
commit 25ea25368a

View File

@ -122,13 +122,31 @@ Signed-off-by: Random J Developer <random@developer.example.org>
The format can be described more formally as follows: The format can be described more formally as follows:
```text ```text
<subsystem>: <what changed> <component>: <subject of the change>
<BLANK LINE> <BLANK LINE>
<why this change was made> <paragraph(s) with reason/description>
<BLANK LINE> <BLANK LINE>
<footer> <signed-off-by>
``` ```
The `component` in the subject of the commit message can be one of the following:
* `cephfs`: bugs or enhancements related to CephFS
* `rbd`: bugs or enhancements related to RBD
* `doc`: documentation updates
* `util`: utilities shared between components use `cephfs` or `rbd` if the
change is only relevant for one of the type of storage
* `journal`: any of the journalling functionalities
* `helm`: deployment changes for the Helm charts
* `deploy`: updates to Kubernetes templates for deploying components
* `build`: anything related to building Ceph-CSI, the executable or container
images
* `ci`: changes related to the Continuous Integration, or testing
* `e2e`: end-to-end testing updates
* `cleanup`: general maintenance and cleanup changes
* `revert`: undo a commit that was merged by mistake, use of one of the other
components is in most cases recommended
The first line is the subject and should be no longer than 70 characters, the The first line is the subject and should be no longer than 70 characters, the
second line is always blank, and other lines should be wrapped at 80 characters. second line is always blank, and other lines should be wrapped at 80 characters.
This allows the message to be easier to read on GitHub as well as in various This allows the message to be easier to read on GitHub as well as in various