Contributing to Kubeapps ¶

Kubeapps maintainers welcome contributions from the community and first want to thank you for taking the time to contribute!

Please familiarize yourself with the Code of Conduct before contributing.

  • CLA: Before you start working with Kubeapps, please read and sign our Contributor License Agreement CLA . If you wish to contribute code and you have not signed our contributor license agreement (CLA), our bot will update the issue when you open a Pull Request. For any questions about the CLA process, please refer to our FAQ .

Ways to contribute ¶

Kubeapps project welcomes many different types of contributions and not all of them need a Pull request. Contributions may include:

  • New features and proposals
  • Documentation
  • Bug fixes
  • Issue Triage
  • Answering questions and giving feedback
  • Helping to onboard new contributors
  • Other related activities

Getting started ¶

Find information about how to set up the development environment on the developer guide .

Contribution Flow ¶

This is a rough outline of what a contributor’s workflow looks like:

  • Make a fork of the repository within your GitHub account
  • Create a topic branch in your fork from where you want to base your work
  • Make commits of logical units
  • Make sure your commit messages are with the proper format, quality and descriptiveness (see below)
  • All commits must be:
  • Push your changes to the topic branch in your fork
  • Create a pull request containing that commit

Kubeapps maintainers team follow the GitHub workflow and you can find more details on the GitHub flow documentation .

Before submitting your pull request use the following checklist:

Pull Request Checklist ¶

  1. Check if your code changes will pass both code linting checks and unit tests.
  2. Ensure your commit messages are descriptive. Kubeapps follow the conventions on How to Write a Git Commit Message . Be sure to include any related GitHub issue references in the commit message. See GFM syntax for referencing issues and commits.
  3. Check the commits and commits messages and ensure they are free from typos.
  4. Make sure all the commits have been properly signed with GPG and contain the signoff.
  5. Any pull request which adds a new feature or changes the behavior of any feature which was previously documented should include updates to the documentation. All documentation lives in this repository.

Reporting Bugs and Creating Issues ¶

For specifics on what to include in your report, please follow the guidelines in the issue and pull request templates when available.

Issues ¶

Need an idea for a project to get started contributing? Take a look at the open issues . Also check to see if any open issues are labeled with good first issue or help wanted .

When contributing to Kubeapps, please first discuss the change you wish to make via an issue with this repository before making a change.

Kubeapps distribution is delegated to the official Bitnami Kubeapps chart from the separate Bitnami charts repository. PRs and issues related to the official chart should be created in the Bitnami charts repository.

Bugs ¶

To file a bug report, please first open an issue . The project maintainers team will work with you on your bug report.

Once the bug has been validated, a pull request can be opened to fix the bug.

For specifics on what to include in your bug report, please follow the guidelines in the issue and pull request templates.

Features ¶

To suggest a feature, please first open an issue that will be tagged with kind/proposal , or create a new Discussion . The project maintainers will work with you on your feature request.

Once the feature request has been validated, a pull request can be opened to implement the feature.

For specifics on what to include in your feature request, please follow the guidelines in the issue and pull request templates.

Ask for Help ¶

The best way to reach Kubeapps maintainers team with a question when contributing is to ask on:

Additional Resources ¶

New to Kubeapps?

Roadmap ¶

The near-term and mid-term roadmap for the work planned for the project maintainers is documented in .