👋 Hey, thanks for taking the time to contribute! Your help is appreciated.
Bug reports are always welcome, and should be reported as a GitHub issue.
It's easy to open an issue, all you need to do is to answer the following questions:
- Which version of kube-score are you using?
- What did you do?
- What did you expect to see?
- What did you see instead?
Feature requests are always welcome, this should also be done as a GitHub issue.
There is currently no set template for feature requests, but largely the same template as the issues can be used.
Describe the feature that you would like to see as clearly as possible.
If the feature request is related to a new "check", include example objects (in YAML format) that are OK, and that should trigger a failure.
Code contributions are welcome as GitHub Pull Requests.
kube-score tries to use the same commit message format as the Go programming language.
Example of a good commit message:
score/container: always add a comment if Container Image Pull Policy fails
Fixes #79
The first line of the commit message should contain a short description of the change, prefixed by the primary affected package.
Additional lines can be used if a longer explanation of the change is needed.
Issues should be referenced with the syntax Fixes #123 or Updates #123 to track that this change is related to an issue.
After a PR has been opened, the complete set of tests will be run automatically. All tests needs to pass before the PR can be merged.
kube-score is using bors-ng for merging Pull Requests, after the PR has been approved by a maintainer,
the bors r+ command will be run, this will rebase the PR on master, and run the tests again. If the tests run, the PR will be merged!