Thank you for interest in contributing to KubeVirt Ansible! 🎉👍
The following is a set of guidelines for contributing to this project. These are not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. Please make sure you are welcoming and friendly in all of our spaces.
Please, don't use the issue tracker for support questions. Stop by the #kubevirt chat channel on freenode IRC or contact us on the KubeVirt Google Group.
Before creating bug reports, please check a list of known issues to see if the problem has already been reported.
If not, go ahead and make one! Be sure to include a descriptive title and clear description and please include as many details as possible to help maintainers reproduce the issue and resolve it faster. If possible, add a code sample or an executable test case demonstrating the expected behavior that is not occurring.
Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
Enhancement suggestions are tracked as GitHub issues. When you are creating an enhancement issue, use a clear and descriptive title and provide a clear description of the suggested enhancement in as many details as possible.
To submit changes, please send a GitHub Pull Request.
- Before submitting a PR, please read the Styleguides to know more about coding conventions used in this project.
- Always fork KubeVirt Ansible and create a new branch with a descriptive name for each pull request to avoid intertwingling different features or fixes on the same branch.
- Always do "git pull --rebase" and "git rebase" vs "git pull" or "git merge".
- Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
Before merging, a PR needs to pass the review of two maintainers' and CI tests. The PR should be up to date with the current master branch and has no requested changes.
In addition for allowing deployment of KubeVirt via Ansible, the KubeVirt-Ansible project is open for any contributions from additional projects which aims to integrate with KubeVirt, such as a specific storage or network project. The integration will be in the form of Ansible roles per component which will later be integrated into a main Ansible Playbook Bundle (APB).
To document a new role, use the README.md template.
To add a component into the KubeVirt APB, import the component playbook in the main kubevirt.yml playbook. Finally, add new paramaters or plans to the APB so they are displayed in the catalog UI.
So far we've been focused mostly on using Ansible to deploy various projects such as KubeVirt on OpenShift or Kubernetes (K8S). However, to really verify if the deployment actually worked, we have to run misc functional tests which will verify the various features the deployed project brought. Currently, the tests are part of the KubeVirt repo under tests.
-
Always write a clear log message for your commits
-
Use the present tense ("Add feature" not "Added feature")
-
Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
-
Limit the first line to 72 characters or less
$ git commit -m "A brief summary of the commit > > A paragraph describing what changed and its impact." -
Reference issues and pull requests as
Fix issue 13
- Readability is one of the most important goals for this project
- Comment any non-trivial code where someone might not know why you are doing something in a particular way
- Commenting above a line is preferable to commenting at the end of a line
- Use descriptive variable names instead of variables like 'x, y, a, b, foo, boo'
- Please ensure all code changes reflected in documentation accordingly.
For me codding guidelines please see Additional Links.
To see the list of KubeVirt Ansible Contributors, please
- Check the Contributors page or
- Run
git shortlog -snein a cloned KubeVirt Ansible git repository.
Thank you! ❤️ ❤️ ❤️
KubeVirt Team