werf is an Open Source project, and we are thrilled to develop and improve it in collaboration with the community.
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.
-
Clone the project:
git clone https://github.com/[GITHUB_USERNAME]/werf
-
Prepare an environment. To build and run werf locally, you'll need to at least have the following installed:
-
Make changes.
-
Build werf:
task build # The built werf binary will be available in the bin directory.
-
Do manual testing.
-
Run tests:
task test:unit task test:integration task test:e2e
-
Format and lint your code:
task format lint
-
Commit changes:
- Follow The Conventional Commits specification.
- Sign off every commit you contributed as an acknowledgment of the DCO.
-
Push commits.
-
Create a pull request.
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>
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 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
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
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.
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.
A concise, hyphen-separated phrase in kebab-case that clearly describes the main focus of the branch.
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.
The documentation is made with Jekyll and contained within ./docs
. See the docs DEVELOPMENT.md for information about developing process.