Documentation
About Kubeapps
Tutorials
- Get Started with Kubeapps
- Using an OIDC provider
- Managing Carvel packages
- Managing Flux packages
- Kubeapps on TKG
How-to guides
- Using the dashboard
- Access Control
- Basic Form Support
- Custon App View Support
- Custom Form Component Support
- Multi-cluster Support
- Offline installation
- Private Package Repository
- Syncing Package Repositories
- Using an OIDC provider with Pinniped
Background
Reference
About the project
Contributing to Kubeapps ¶
Contributions to Kubeapps are welcome. Here are some things to help you get started.
Code of Conduct ¶
Please note we have a Code of Conduct , please follow it in all your interactions with the project.
Roadmap ¶
The near-term and mid-term roadmap for the work planned for the project maintainers is documented in ROADMAP.md .
Community Meetings ¶
Please join us during our online community meetings, occurring every two Mondays at 10:30 AM UTC. Add the ics invitation to your calendar.
Discussion ¶
Got a question, comment, or idea? Please don’t hesitate to reach out via GitHub Discussions , GitHub Issues , or in the Kubernetes Slack Workspace within the #kubeapps channel .
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 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.
Pull Request Process ¶
- Ensure any install or build dependencies are removed before the end of the layer when doing a build.
- Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.
- Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would represent. The versioning scheme we use is SemVer .
- You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.
VMware Contributors License Agreement (CLA) ¶
Kubeapps project team welcomes contributions from the community. 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 .
Documentation ¶
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.
Learning about Kubeapps ¶
New to Kubeapps?
- Start here to learn how to install and use Kubeapps: Getting started in Kubeapps
- Start here to learn how to develop for Kubeapps components: Kubeapps Developer guidelines
- Other more detailed documentation can be found at: Kubeapps Docs