First of all, thank you for your interest in contributing to k8s-extensions
! We welcome contributions from everyone and are glad you're here.
- Fork the
k8s-extensions
repository on GitHub. - Clone your fork locally on your machine.
- Set up your development environment.
Here are some basic steps for code contributions:
- Create an issue in the
k8s-extensions
repository on GitHub. Mention clear description stating what is the issue about and if its a new extension or bugfix. - Create a new branch for each extension or bug fix.
- Write your code. (See below section on creating an extension)
- Commit your changes. Make sure your commit messages are clear and follow the commit message conventions.
- Push your changes to your fork.
- Create a pull request.
- Address any review comments.
Note: You can take advantage of
templates
folder which contains a boilerplate to get started with building an extension.You can either run
./generate <extensionType>
or directly copy the desired extension type boilerplate in root directory
This guide explains how to create an extension for the K8s Extensions Installer. An extension consists of a manifest file and a folder named k8s, helm, or terraform, depending on the type of extension.
An extension consists of the following components:
- Manifest file: A YAML file containing metadata and input parameters for the extension.
- Configuration folder: A folder named k8s, helm, or terraform containing the necessary files and templates for the specific configuration management tool. Please use
terraform
as the name of folder to store tf files and that folder should be paraller to manifest file.
The manifest file is a YAML file that includes the following information:
- name: The name of the extension.
- description: A brief description of the extension.
- type: The type of extension (either k8s, helm, or terraform).
- version: The version of the extension.
- author: The author of the extension.
- inputs: A list of input parameters for the extension.
Each input parameter in the manifest file has the following attributes:
- name: The name of the input parameter.
- type: The data type of the input parameter (either string or integer).
- required: Whether the input parameter is required or not.
- description: A description of the input parameter.
- default: The default value for the input parameter, if not provided by the user (optional).
Here's an example of a manifest file:
name: nginx
description: A brief description of the extension
type: k8s
version: 1.0.0
author: Vishal Saugat
inputs:
- name: appname
type: string
required: true
description: Name of the application
- name: author
type: string
required: true
description: Author of the application
- name: replicas
type: integer
required: false
default: 4
description: Number of replicas
Create a folder named k8s, helm, or terraform based on the type of extension specified in the manifest file. This folder should contain the necessary files and templates for the chosen configuration management tool.
For example, for a Kubernetes extension, the k8s folder might contain YAML files for creating deployments, services, and other Kubernetes resources.
Here's a sample template file that can be located in the k8s folder if the extension type is k8s:
apiVersion: apps/v1
kind: Deployment
metadata:
name: '{{.appname}}'
namespace: default
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
created-by: '{{.author}}'
spec:
containers:
- name: nginx-containers
image: nginx
ports:
- containerPort: 80
resources: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd-deployment
namespace: httpd
spec:
selector:
matchLabels:
app: httpd
replicas: {{.replicas}}
template:
metadata:
labels:
app: httpd
spec:
containers:
- name: httpd-containers
image: httpd
ports:
- containerPort: 80
Here are some basic steps for code contributions:
- Create a new branch for each feature or bug fix.
- Write your code.
- Write tests that cover your changes.
- Run tests and make sure all tests pass.
- Commit your changes. Make sure your commit messages are clear and follow the commit message conventions.
- Push your changes to your fork.
- Create a pull request.
- Address any review comments.
Note: You can take advantage of
templates
folder which contains a boilerplate to get started with building an extension.You can either run
./generate <extensionType>
or directly copy the desired extension type boilerplate in root directory
Please follow the Conventional Commits specification. This leads to more readable messages and helps to follow the changes in the project.
Bugs can be reported by opening an issue on the GitHub repository. Please provide as much detail as possible, including steps to reproduce the issue, the expected behavior, and the observed behavior.
Feature requests can also be made by opening an issue on the GitHub repository. Describe the feature, provide use cases if possible, and explain why this feature would be valuable to the project.
If you have any questions about contributing to the project, please open an issue and we will do our best to help.