Skip to content

Latest commit

 

History

History
146 lines (100 loc) · 4.59 KB

CONTRIBUTING.md

File metadata and controls

146 lines (100 loc) · 4.59 KB
Raw

Contributing to werf

werf is an Open Source project, and we are thrilled to develop and improve it in collaboration with the community.

Feedback

The first thing we recommend is to check the existing issues, discussion threads, and documentation - 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.

Contributing code

  1. Fork the project.

  2. Clone the project:

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

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

    • Git 2.18.0+
    • Go 1.11.4+
    • Docker
    • go-task (build tool to run common workflows)
    • ginkgo (testing framework required to run tests)

  4. Make changes.

  5. Build werf:

    task build # The built werf binary will be available in the bin directory.

  6. Do manual testing.

  7. Run tests:

    task test:unit
task test:integration
task test:e2e

  8. Format and lint your code:

    task format lint

  9. Commit changes:

  10. Push commits.

  11. Create a pull request.

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>

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.
- giterminism
- build
  - stapel
  - dockerfile
  - docker
  - buildah
  - stages
- deploy
  - chart
  - tracking
  - plan
- bundle
- cleanup-registry
- other

# Maintaining, improving code quality and development workflow. 
- ci
- release
- 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.

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.

Coding Conventions

Improving the documentation

The documentation is made with Jekyll and contained within ./docs. See the docs DEVELOPMENT.md for information about developing process.