One of the best ways to improve your programming skills is to get involved with a community, meet people, and find new opportunities is to collaborate with others in open source projects. If it’s your first time creating a pull request it can be quite intimidating. I’m here to tell you to not be afraid of making even a tiny change because it’s likely that your pull request will help make Zenko better.
Feel free to ask
The best idea is to reach out to us first. We can discuss what you want to contribute and check whether someone is working on a similar change already or if you can get started right away. Wherever possible, we want to make sure you have a clear path to make your work easier, faster, relevant. Or if you are not sure what exactly you can do, we would be happy to help you find a way to contribute.
To do that you can create an issue on GitHub or ask your question on the Zenko forum.
Where you can find Zenko
If you visit the Zenko repository you will find that it includes installation resources (helm charts) to deploy the full Zenko stack over an orchestration system. A helm chart is a collection of files that describes a related set of Kubernetes resources.
The actual components of Zenko are spread across two repositories: Backbeat (core engine for asynchronous replication, optimized for queuing metadata updates and dispatching work to long-running tasks in the background) and CloudServer (Node.js implementation of the Amazon S3 protocol on the front-end and backend storage capabilities to multiple clouds, including Azure and Google).
Another great way to help is contributing to Zenko-specs (repository that contains design.mds of upcoming features where you are more than welcome to suggest or comment). Additionally, every repository has a design.md describing the existing feature.
Let’s get down to it
Step 1
After you have chosen a repository to contribute to, go ahead and fork it to your GitHub account. In the forked repository, you have “write” access and can push changes. Eventually, you will contribute back to the original repository using pull requests.
Let’s say you want to add some changes to Backbeat.
Clone the forked repository to your local machine:
$ git clone https://github.com/dashagurova/backbeat.git $ cd backbeat
Step 2
You will find yourself in the default development branch of some version(development/major.minor). There is no master branch. Want to know why? Learn more about Scality’s own GitWaterFlow delivery model here.
The next step is to create your own branch where all your work will be done:
$ git checkout -b type_of_branch/name_your_fix
Step 3
Important: “type_of_branch” should be one of these prefixes: feature/*, improvement/*, bugfix/*, hotfix/*.
Do your magic! Fix something, improve existing code, add a feature or document one.
Note: Scality utilizes TDD (Test Driven Development) model, so it is highly appreciated if any code submission is associated with related unit tests or changes on the existing tests (more info), depending on the type of code that was submitted. You will find a tests/ folder in the root directory of every repository.
Step 4
While working in your branch, you might end up having many commits. In order to keep things easy to navigate, it is common practice to “squash” many small commits down to a few or a single logical changeset before submitting a pull request.
To squash three commits into one, you can do the following:
$ git rebase -i HEAD~3 Where 3 is the number of commits
In the text editor that comes up, replace the words “pick” with “squash” next to the commits you want to squash into the commit before it.
Save and close the editor, and git will combine the squashed commits with the one before it. Git will then give you the opportunity to change your commit message to describe your fix or feature (in no more than 50 characters).
Step 5
If you’ve already pushed commits to GitHub and then squashed them locally, you will have to force the push to your branch.
$ git push -f origin type_of_branch/myfix
Otherwise just:
$ git push origin type_of_branch/myfix
Important: make sure that you push the changes to your type_of_branch/myfix!
Make the pull request
Now you’re ready to create a pull request. You can open a pull request to the upstream repository (original repository) or in your fork. One option is to create it in your fork and search for bugfix/myfix branch. Hit “New pull request”.
After that, you are presented with the page where you can go into the details about your work.
After you click “Create pull request,” you are greeted by Bert-E. Bert-E is the gatekeeping and merging bot Scality developed in-house to automate GitWaterFlow. Its purpose is to help developers merge their feature branches on multiple development branches.
Now it’s time to relax and have some tea. Our core developers will review your request and get back to you shortly. If you are willing to contribute code, docs, issues, proposals or just ask a question, come find me on the forum.
