Hi there! Are you interested in contributing to Kubes? We’d love your help. Kubes is an open-source project, built one contribution at a time by users like you.
Where to get help or report a problem
Ways to contribute
Whether you’re a developer, an infrastructure engineer, or just an enthusiast, there are lots of ways to contribute. Here are a few ideas:
- Install Kubes on your computer and kick the tires. Does it work? Does it do what you’d expect? If not, open an issue and let us know.
- Comment on some of the project’s open issues. Have you experienced the same problem? Know a workaround? Do you have a suggestion for how the feature could be better?
- Read through the documentation, and click the “improve this page” button, any time you see something confusing or have a suggestion for something that could be improved.
- Find an open issue (especially those labeled
help wanted), and submit a proposed fix. If it’s your first pull request, we promise we won’t bite and are glad to answer any questions.
- Help evaluate open pull requests, by testing the changes locally and reviewing what’s proposed.
Submitting a pull request
Pull requests generally
The smaller the proposed change, the better. If you’d like to propose two unrelated changes, submit two pull requests.
The more information, the better. Make judicious use of the pull request body. Describe what changes were made, why you made them, and what impact they will have for users.
If this is your first pull request, it may help to understand GitHub Flow.
If you’re submitting a code contribution, be sure to read the code contributions section below.
Submitting a pull request via github.com
Many small changes can be made entirely through the github.com web interface.
- Navigate to the file within boltops-tools/kubes that you’d like to edit.
- Click the pencil icon in the top right corner to edit the file.
- Make your proposed changes.
- Click “Propose file change.”
- Click “Create pull request.”
- Add a descriptive title and detailed description for your proposed change. The more information, the better.
- Click “Create pull request.”
That’s it! You’ll be automatically subscribed to receive updates as others review your proposed change and provide feedback.
Submitting a pull request via Git command line
- Fork the project by clicking “Fork” in the top right corner of boltops-tools/kubes.
- Clone the repository locally
git clone https://github.com/<your-username>/kubes.
- Fetch submodules
git submodule init && git submodule update.
- Create a new, descriptively named branch to contain your change (
git checkout -b my-awesome-feature).
- Hack away, add tests. Not necessarily in that order.
- Make sure everything still passes by running
bundle exec rspec(see the tests section below)
- Push the branch up (
git push origin my-awesome-feature).
- Create a pull request by visiting
https://github.com/<your-username>/kubesand following the instructions at the top of the screen.
Proposing updates to the documentation
We want the Kubes documentation to be the best it can be. We’ve open-sourced our docs and we welcome any pull requests if you find it lacking.
How to submit changes
One gotcha, all pull requests should be directed at the
master branch (the default branch).
Interesting in submitting a pull request? Awesome. Read on. There are a few common gotchas that we’d love to help you avoid.
Tests and documentation
Any time you propose a code change, you should also include updates to the documentation and tests within the same pull request.
If your contribution changes any Kubes behavior, make sure to update the documentation. Documentation lives in the
docs folder. It’s a Jekyll site and can be started with
cd docs && bin/web. If the docs are missing information, please feel free to add it in. Great docs make a great project. Include changes to the documentation within your pull request, and once merged,
https://kubes.guru.com will be updated.
- If you’re creating a small fix or patch to an existing feature, a simple test is more than enough. You can usually copy/paste from an existing example in the
Code contributions generally
- Don’t bump the Gem version in your pull request (if you don’t know what that means, you probably didn’t).
To run the test suite by running the following command:
bundle exec rspec
Thanks! Hacking on Kubes should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation!