Contribute to Dgraph
Setting Up the Development Environment
- Install Git (may be already installed on your system, or available through your OS package manager)
- Install Go 1.8 or above
Setup Dgraph from source repo
$ go get -u -v -t github.com/dgraph-io/dgraph/...
This will put the source code in a Git repo under
$GOPATH/src/github.com/dgraph-io/dgraph and compile the binaries to
Setup Badger from source repo
Dgraph source repo vendors its own version of Badger. If you are just working on Dgraph, you do not necessarily need to check out Badger from its own repo. However, if you want to contribute to Badger as well, you will need to check it out from its own repo.
$ go get -t -v github.com/dgraph-io/badger
This will put the source code in a Git repo under
We use protocol buffers to serialize data between our server and the Go client and also for inter-worker communication. If you make any changes to the
.proto files, you would have to recompile them.
protoc compiler which is required for compiling proto files used for gRPC communication. Get
protoc version 3.0.0 or above from GitHub releases page (look for the binary releases at the bottom, or compile from sources following the instructions).
We use gogo protobuf in Dgraph. To get the protocol buffer compiler plugin from gogo run
$ go get -u github.com/gogo/protobuf/protoc-gen-gofast
To compile the proto file using the
protoc plugin and the gogo compiler plugin run the script
gen.sh from within the directory containing the
$ cd protos $ ./gen.sh
This should generate the required
test script in the root folder.
$ ./test Running tests. Ignoring vendor folder. ok github.com/dgraph-io/dgraph/algo 0.013s ok github.com/dgraph-io/dgraph/client 0.029s ok github.com/dgraph-io/dgraph/client_test 2.841s …
go test in the root folder.
$ go test ./... ok github.com/dgraph-io/badger 24.853s ok github.com/dgraph-io/badger/skl 0.027s ok github.com/dgraph-io/badger/table 0.478s ok github.com/dgraph-io/badger/y 0.004s
Doing a release
- Create a branch called
release/v<x.y.z>from master. For e.g.
release/v1.0.5. Look at the diff between the last release and master and make sure that
CHANGELOG.mdhas all the changes that went in. Also make sure that any new features/changes are added to the docs under
wiki/contentto the relevant section.
- Test any new features or bugfixes and then tag the final commit on the release branch like:
git tag -s -a v1.0.5
- Push the release branch and the tagged commit.
git push origin release/v<x.y.z> git push origin v<x.y.z>
Travis CI would run the
contrib/nightly/upload.shscript when a new tag is pushed. This script would create the binaries for
windowsand also upload them to Github after creating a new draft release. It would also publish a new docker image for the new release as well as update the docker image with tag
latestand upload them to docker hub.
masterbranch and merge the tag to it and push it.
git checkout master git merge v<x.y.z> git push origin master
Once the draft release is published on Github by Travis, modify it to add the release notes. The release notes would mostly be the same as changes for the current version in
CHANGELOG.md. Finally publish the release and announce to users on community Slack.
To make sure that docs are added for the newly released version, add the version to
wiki/scripts/build.sh. It is also important for a release branch for the version to exist, otherwise docs won’t be built and published for it. SSH into the server serving the docs and pull the latest version of
wiki/scripts/build.shfrom master branch and rerun it so that it can start publishing docs for the latest version.
If any bugs were fixed with regards to query language or in the server then it is a good idea to deploy the latest version on
Over years of writing big scalable systems, we are convinced that striving for simplicity wherever possible is the only way to build robust systems. This simplicity could be in design, could be in coding, or could be achieved by rewriting an entire module, that you may have painstakingly finished yesterday.
- Pull requests are welcome, as long as you’re willing to put in the effort to meet the guidelines.
- Aim for clear, well written, maintainable code.
- Simple and minimal approach to features, like Go.
- Refactoring existing code now for better performance, better readability or better testability wins over adding a new feature.
- Don’t add a function to a module that you don’t use right now, or doesn’t clearly enable a planned functionality.
- Don’t ship a half done feature, which would require significant alterations to work fully.
- Avoid Technical debt like cancer.
- Leave the code cleaner than when you began.
- We’re following Go Code Review.
go fmtto format your code before committing.
- If you see any code which clearly violates the style guide, please fix it and send a pull request. No need to ask for permission.
- Avoid unnecessary vertical spaces. Use your judgment or follow the code review comments.
- Wrap your code and comments to 100 characters, unless doing so makes the code less legible.
Every new source file must begin with a license header.
Badger repo and the dgraph clients(dgo, dgraph-js, pydgraph and dgraph4j) are licensed under the Apache license:
/* * Copyright 2016-2018 Dgraph Labs, Inc. and Contributors * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */
All the code in the Dgraph repo is licensed under the Apache license with the Commons Clause restriction:
/* * Copyright 2017-2018 Dgraph Labs, Inc. and Contributors * * This file is available under the Apache License, Version 2.0, * with the Commons Clause restriction. */
Signed commits help in verifying the authenticity of the contributor. We use signed commits in Dgraph, and we prefer it, though it’s not compulsory to have signed commits. This is a recommended step for people who intend to contribute to Dgraph on a regular basis.
Follow instructions to generate and setup GPG keys for signing code commits on this Github Help page.