Skip to content

Latest commit

 

History

History
174 lines (120 loc) · 5.33 KB

CONTRIBUTING.md

File metadata and controls

174 lines (120 loc) · 5.33 KB
Raw

Contributing

Feedback

The first thing we recommend is to check the existing issues — there may already be a discussion or solution on your topic. If not, choose the appropriate way to address the issue on the new issue form.

Code contributions

  1. Prepare an environment. To build and run common workflows locally, you'll need to at least have the following installed:

  2. Fork the project.

  3. Clone the project:

    git clone https://github.com/[GITHUB_USERNAME]/virtualization

  4. Create branch following the branch name convention:

    git branch -b feat/core/add-new-feature

  5. Make changes.

  6. Commit changes:

  7. Push commits.

  8. Create a pull request following the pull request name convention.

Images

The module images are located in the ./images directory.

Images, such as build images or images with binary artifacts, should not be included in the module. To do so, they must be labeled as follows in the werf.inc.yaml file: final: false.

Conventions

Commit message

Each commit message consists of a header and a body. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>

Examples:

  • feat(api): bump resource version to v1beta1
  • feat(images): implement ImageLost phase
  • feat(images, vi): add PVC as a storage
  • fix(vm, vmclass): fix unsupported type of class
  • refactor(core): rename 3rd party resources
  • docs(module): describe how to install module
  • chore(core): use alt linux as base image
  • chore: update go dependencies

Type

Must be one of the following:

  • feat: new features or capabilities that enhance the user's experience.
  • fix: bug fixes that enhance the user's experience.
  • refactor: a code changes that neither fixes a bug nor adds a feature.
  • docs: updates or improvements to documentation.
  • test: additions or corrections to tests.
  • chore: updates that don't fit into other types.

Scope

Scope indicates the area of the project affected by the changes. The scope can consist of a top-level scope, which broadly categorizes the changes, and can optionally include nested scopes that provide further detail.

Supported scopes are the following:

# The end-user functionalities, aiming to streamline and optimize user experiences.
# NOTE! The api scope should be omitted if a more specific sub-scope is used.
- api
  - vm
    - vmop
    - vmbda
    - vmclass
    - vmip
    - vmipl
    - vdsnapshot
    - vmsnapshot
    - vmrestore
  - disks
    - vd
  - images
    - vi
    - cvi

# Core mechanisms and low-level system functionalities.
- core
  - api-service
  - vm-route-forge
  - kubevirt
  - kube-api-rewriter
  - cdi
  - dvcr

# Integration with the Deckhouse.
- module

# User metrics, alerts, dashboards, and logs that provide insights into system performance and health.
- observability

# Maintaining, improving code quality and development workflow.
- ci
- lint
- format
- gen
- dev

Subject

The subject contains a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Branch name

Each branch name consists of a type, scope, and a short-description:

<type>/<scope>/<short-description>

When naming branches, only the top-level scope should be used. Multiple or nested scopes are not allowed in branch names, ensuring that each branch is clearly associated with a broad area of the project.

Examples:

  • feat/disks/support-new-image-source
  • chore/ci/speed-up-builds

Short description

A concise, hyphen-separated phrase in kebab-case that clearly describes the main focus of the branch.

Pull request name

Each pull request title should clearly reflect the changes introduced, adhering to the header format of a commit message, typically mirroring the main commit's text in the PR.

Examples

  • feat(vm): add live migration capability
  • docs(api): update REST API documentation for clarity

Coding