Skip to content

Latest commit

 

History

History
86 lines (54 loc) · 4.01 KB

create-pull-request.md

File metadata and controls

86 lines (54 loc) · 4.01 KB

Create a pull request

We're excited that you're considering making a contribution to the KubeVela project! This document guides you through the process of creating a pull request.

Before you begin

We know you're excited to create your first pull request. Before we get started, read these resources first:

Your first pull request

If this is your first time contributing to an open-source project on GitHub, make sure you read about Creating a pull request.

To increase the chance of having your pull request accepted, make sure your pull request follows these guidelines:

  • Title and description matches the implementation.
  • Commits within the pull request follow the Formatting guidelines.
  • The pull request closes one related issue.
  • The pull request contains necessary tests that verify the intended behavior.
  • If your pull request has conflicts, rebase your branch onto the main branch.

If the pull request fixes a bug:

  • The pull request description must include Closes #<issue number> or Fixes #<issue number>.
  • To avoid regressions, the pull request should include tests that replicate the fixed bug.

Please refer to the code conventions for better code style and conventions.

Code review

Once you've created a pull request, the next step is to have someone review your change. A review is a learning opportunity for both the reviewer and the author of the pull request.

If you think a specific person needs to review your pull request, then you can tag them in the description or in a comment. Tag a user by typing the @ symbol followed by their GitHub username.

We recommend that you read How to do a code review to learn more about code reviews.

Formatting guidelines

A well-written pull request minimizes the time to get your change accepted. These guidelines help you write good commit messages and descriptions for your pull requests.

Commit message format

KubeVela uses the guidelines for commit messages outlined in How to Write a Git Commit Message, with the following additions:

Area

The area should use upper camel case, e.g. UpperCamelCase.

Prefer using one of the following areas:

  • Application: Changes to the application controller.
  • Component: Changes to the component related code or definition controller.
  • Trait: Changes to the trait related code or definition controller.
  • CUE: Changes to the CUE related logic.
  • Docs: Changes to documentation.
  • AppConfig: Changes to AppConfig related code.

Examples

  • Application: Support workflow in application controller
  • CUE: Fix patch parse issues
  • Docs: Changed url to URL in all documentation files

Pull request titles

The KubeVela team squashes all commits into one when we accept a pull request. The title of the pull request becomes the subject line of the squashed commit message. We still encourage contributors to write informative commit messages, as they become a part of the Git commit body.

We use the pull request title when we generate change logs for releases. As such, we strive to make the title as informative as possible.

Make sure that the title for your pull request uses the same format as the subject line in the commit message.

Pass all the CI checks

Before merge, All test CI should pass green. The codecov/project should also pass. This means the coverage should not drop. See Codecov commit status.