Skip to content

Latest commit

 

History

History
155 lines (113 loc) · 5.95 KB

CONTRIBUTING.md

File metadata and controls

155 lines (113 loc) · 5.95 KB
Raw

Contributing to the Keptn Lifecycle Toolkit

We are thrilled to have you join us as a contributor! The Keptn Lifecycle Toolkit is a community-driven project and we greatly value collaboration. There are various ways to contribute to the Lifecycle Toolkit, and all contributions are highly valued. Please, explore the options below to learn more about how you can contribute.

Before you get started

Code of Conduct

Please make sure to read and observe our Code of Conduct.

This document lays out how to get you started in contributing to Keptn Lifecycle Toolkit, so please read on.

How to Start?

If you are worried or don’t know where to start, check out our next section explaining what kind of help we could use and where you can get involved. You can reach out with the questions to Lifecycle Toolkit Channels on Slack and a mentor will surely guide you!

Prerequisites

See Set up the development environment for information about how to set up an environment in which you can develop and test software for Keptn.

Related Technologies

Please check Related Technologies.

Linter Requirements

Please check Linter Requirements.

Submit a Pull Request 🚀

At this point, you should switch back to the main branch in your repository, and make sure it is up to date with main branch of Keptn Lifecycle Toolkit:

git remote add upstream https://github.com/keptn/lifecycle-toolkit.git
git checkout main
git pull upstream main

Then update your feature branch from your local copy of main and push it:

git checkout feature/123/foo
git rebase main
git push --set-upstream origin feature/123/foo

Note: All PRs must include a commit message with a description of the changes made!

Make sure you sign off your commits. To do this automatically check this. Finally, go to GitHub and create a Pull Request. There should be a PR template already prepared for you. If not, you will find it at .github/pull_request_template.md. Please describe what this PR is about and add a link to relevant GitHub issues. If you changed something that is visible to the user, please add a screenshot. Please follow the conventional commit guidelines for your PR title.

If you only have one commit in your PR, please follow the guidelines for the message of that single commit, otherwise the PR title is enough. You can find a list of all possible feature types here.

An example for a pull request title would be:

feat(api): New endpoint for feature X (#1234)

If you have breaking changes in your PR, it is important to note them in the PR description but also in the merge commit for that PR.

When pressing "squash and merge", you have the option to fill out the commit message. Please use that feature to add the breaking changes according to the conventional commit guidelines. Also, please remove the PR number at the end and just add the issue number.

An example for a PR with breaking changes and the according merge commit:

feat(bridge): New button that breaks other things (#345)

BREAKING CHANGE: The new button added with #345 introduces new functionality that is not compatible with the previous type of sent events.

If your breaking change can be explained in a single line you can also use this form:

feat(bridge)!: New button that breaks other things (#345)

Following those guidelines helps us create automated releases where the commit and PR messages are directly used in the changelog.

In addition, please always ask yourself the following questions:

Based on the linked issue, what changes within the PR would you expect as a reviewer?

Your PR will usually be reviewed by the Keptn Lifecycle Toolkit team within a couple of days, but feel free to let us know about your PR via Slack.

Commit Types

Type can be:

  • feat: a new feature
  • fix: a bug fix
  • build: changes that affect the build system or external dependencies
  • chore: other changes that don't modify source or test files
  • ci: changes to our CI configuration files and scripts
  • docs: documentation only changes
  • perf: a code change that improves performance
  • refactor: a code change that neither fixes a bug nor adds a feature
  • revert: reverts a previous commit
  • style: changes that do not affect the meaning of the code
  • test: adding missing tests or correcting existing tests

Developer Certification of Origin (DCO)

All commits must be accompanied by a DCO sign-off. See DCO for more information.