Thank you for your interest in contributing to our project. Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.
Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.
Specifically, if you wish to contribute a new Kubectl Asset with a different kubectl version, jump to Contributing a new Kubectl Asset.
Similar to kubernetes, we support the most recent three minor versions. This means that we continue to upgrade dependencies for the most recent three versions.
We also plan to have the default branch of this repository to be the latest released version. If that is not the case, please raise a GitHub Issue with us!
We welcome you to use the GitHub issue tracker to report bugs or suggest features.
When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
- A reproducible test case or series of steps
- The version of our code being used
- Any modifications you've made relevant to the bug
- Anything unusual about your environment or deployment
Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:
- You are working against the latest source on the kubectl-v21/main branch.
- You check existing open, and recently merged, pull requests to make sure someone else hasn't addressed the problem already.
- You open an issue to discuss any significant work - we would hate for your time to be wasted.
To send us a pull request, please:
- Fork the repository.
- Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
- Ensure local tests pass.
- Commit to your fork using clear commit messages.
- Send us a pull request, answering any default questions in the pull request interface.
- Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.
GitHub provides additional document on forking a repository and creating a pull request.
If you would like to contribute a new Kubectl Asset with a different kubectl version, please follow these steps:
- Open a new GitHub issue titled
Feature Request: Asset with kubectl vX.Y.Z
. We will track the progress of the new Asset in the issue. - If we decide to support the requested version, a maintainer will open a new branch,
kubectl-vY/main
(Y is the minor version) and update the issue accordingly. The maintainer will also open a branch calledkubectl.vY
in the corresponding go binding repository,cdklabs/awscdk-kubectl-go
. - Fork the repository and fetch the
kubectl-vY/main
branch locally, and modify the source off of that. - Specifically:
- change
README.md
to reflect the new versions of kubectl and helm that the asset will include. - change
KUBECTL_VERSION
andHELM_VERSION
inlayer/Dockerfile
to reflect the new versions. TheHELM_VERSION
you select should be the highest version compatible with theKUBECTL_VERSION
according to the helm docs. For example, ifKUBECTL_VERSION
is v1.20.x, then theHELM_VERSION
should be v3.8.x. - change
SPEC_VERSION
in.projenrc.js
to reflect the new minor version of kubectl. For example, ifKUBECTL_VERSION
is v1.25.0, thenSPEC_VERSION
should be 25. - for an example of code changes done for kubectl v1.22.0, see this PR.
- change
- Run
npx projen
to update the github workflows. - Run
npx projen integ:kubectl-layer:deploy
to ensure that the new versions in the Dockerfile can be successfully downloaded. Runnpx projen integ:kubectl-layer:snapshot
ifdeploy
succeeds and the snapshot does not get updated. - Run
yarn build
to ensure everything builds correctly. - Commit to your fork and submit a pull request to the repository, ensuring that you are targeting the correct
kubectl-vY/main
branch. - A maintainer will review your contribution from there!
⚠️ IMPORTANT⚠️ The maintainer should go into the repository settings and update the default branch to the new, latest version.
This repository consists of multiple branches, with each branch corresponding to a specific Kubectl version.
For example, kubectl-v24/main
is the branch that releases a Lambda Layer that bundles kubectl version 1.24.
Sometimes, a contribution made to a specific branch should be propogated to other branches in this repository as well.
To do this, you can add backport-to-kubectl-v21+
as a label to the PR that tells Mergify to backport when the PR is merged.
This will backport to all versions of kubectl except kubectl v1.20, which is special and does not expose a Lambda Layer.
If you think you need to backport to a specific subset of branches instead, you can ask a maintainer to backport via a mergify comment:
@Mergifyio backport kubectl-v21/main kubectl-v22/main
Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any 'help wanted' issues is a great place to start.
This project has adopted the Amazon Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.
If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our vulnerability reporting page. Please do not create a public github issue.
See the LICENSE file for our project's licensing. We will ask you to confirm the licensing of your contribution.