PageRenderTime 52ms CodeModel.GetById 19ms RepoModel.GetById 0ms app.codeStats 0ms

/vendor/github.com/influxdata/influxdb/CONTRIBUTING.md

https://gitlab.com/unofficial-mirrors/openshift-origin
Markdown | 280 lines | 206 code | 74 blank | 0 comment | 0 complexity | fc34b3c8cc2ffdb457885894e2868bba MD5 | raw file
  1. Contributing to InfluxDB
  2. ========================
  3. Bug reports
  4. ---------------
  5. Before you file an issue, please search existing issues in case it has already been filed, or perhaps even fixed. If you file an issue, please include the following.
  6. * Full details of your operating system (or distribution) e.g. 64-bit Ubuntu 14.04.
  7. * The version of InfluxDB you are running
  8. * Whether you installed it using a pre-built package, or built it from source.
  9. * A small test case, if applicable, that demonstrates the issues.
  10. Remember the golden rule of bug reports: **The easier you make it for us to reproduce the problem, the faster it will get fixed.**
  11. If you have never written a bug report before, or if you want to brush up on your bug reporting skills, we recommend reading [Simon Tatham's essay "How to Report Bugs Effectively."](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
  12. Test cases should be in the form of `curl` commands. For example:
  13. ```bash
  14. # create database
  15. curl -G http://localhost:8086/query --data-urlencode "q=CREATE DATABASE mydb"
  16. # create retention policy
  17. curl -G http://localhost:8086/query --data-urlencode "q=CREATE RETENTION POLICY myrp ON mydb DURATION 365d REPLICATION 1 DEFAULT"
  18. # write data
  19. curl -X POST http://localhost:8086/write --data-urlencode "db=mydb" --data-binary "cpu,region=useast,host=server_1,service=redis value=61"
  20. # Delete a Measurement
  21. curl -G http://localhost:8086/query --data-urlencode 'db=mydb' --data-urlencode 'q=DROP MEASUREMENT cpu'
  22. # Query the Measurement
  23. # Bug: expected it to return no data, but data comes back.
  24. curl -G http://localhost:8086/query --data-urlencode 'db=mydb' --data-urlencode 'q=SELECT * from cpu'
  25. ```
  26. **If you don't include a clear test case like this, your issue may not be investigated, and may even be closed**. If writing the data is too difficult, please zip up your data directory and include a link to it in your bug report.
  27. Please note that issues are *not the place to file general questions* such as "how do I use collectd with InfluxDB?" Questions of this nature should be sent to the [Google Group](https://groups.google.com/forum/#!forum/influxdb), not filed as issues. Issues like this will be closed.
  28. Feature requests
  29. ---------------
  30. We really like to receive feature requests, as it helps us prioritize our work. Please be clear about your requirements, as incomplete feature requests may simply be closed if we don't understand what you would like to see added to InfluxDB.
  31. Contributing to the source code
  32. ---------------
  33. InfluxDB follows standard Go project structure. This means that all your Go development are done in `$GOPATH/src`. GOPATH can be any directory under which InfluxDB and all its dependencies will be cloned. For full details on the project structure, follow along below.
  34. You should also read our [coding guide](https://github.com/influxdata/influxdb/blob/master/CODING_GUIDELINES.md), to understand better how to write code for InfluxDB.
  35. Submitting a pull request
  36. ------------
  37. To submit a pull request you should fork the InfluxDB repository, and make your change on a feature branch of your fork. Then generate a pull request from your branch against *master* of the InfluxDB repository. Include in your pull request details of your change -- the why *and* the how -- as well as the testing your performed. Also, be sure to run the test suite with your change in place. Changes that cause tests to fail cannot be merged.
  38. There will usually be some back and forth as we finalize the change, but once that completes it may be merged.
  39. To assist in review for the PR, please add the following to your pull request comment:
  40. ```md
  41. - [ ] CHANGELOG.md updated
  42. - [ ] Rebased/mergable
  43. - [ ] Tests pass
  44. - [ ] Sign [CLA](https://influxdata.com/community/cla/) (if not already signed)
  45. ```
  46. Signing the CLA
  47. ---------------
  48. If you are going to be contributing back to InfluxDB please take a
  49. second to sign our CLA, which can be found
  50. [on our website](https://influxdata.com/community/cla/).
  51. Installing Go
  52. -------------
  53. InfluxDB requires Go 1.7.4.
  54. At InfluxDB we find gvm, a Go version manager, useful for installing Go. For instructions
  55. on how to install it see [the gvm page on github](https://github.com/moovweb/gvm).
  56. After installing gvm you can install and set the default go version by
  57. running the following:
  58. gvm install go1.7.4
  59. gvm use go1.7.4 --default
  60. Installing GDM
  61. -------------
  62. InfluxDB uses [gdm](https://github.com/sparrc/gdm) to manage dependencies. Install it by running the following:
  63. go get github.com/sparrc/gdm
  64. Revision Control Systems
  65. -------------
  66. Go has the ability to import remote packages via revision control systems with the `go get` command. To ensure that you can retrieve any remote package, be sure to install the following rcs software to your system.
  67. Currently the project only depends on `git` and `mercurial`.
  68. * [Install Git](http://git-scm.com/book/en/Getting-Started-Installing-Git)
  69. * [Install Mercurial](http://mercurial.selenic.com/wiki/Download)
  70. Getting the source
  71. ------
  72. Setup the project structure and fetch the repo like so:
  73. ```bash
  74. mkdir $HOME/gocodez
  75. export GOPATH=$HOME/gocodez
  76. go get github.com/influxdata/influxdb
  77. ```
  78. You can add the line `export GOPATH=$HOME/gocodez` to your bash/zsh file to be set for every shell instead of having to manually run it everytime.
  79. Cloning a fork
  80. -------------
  81. If you wish to work with fork of InfluxDB, your own fork for example, you must still follow the directory structure above. But instead of cloning the main repo, instead clone your fork. Follow the steps below to work with a fork:
  82. ```bash
  83. export GOPATH=$HOME/gocodez
  84. mkdir -p $GOPATH/src/github.com/influxdata
  85. cd $GOPATH/src/github.com/influxdata
  86. git clone git@github.com:<username>/influxdb
  87. ```
  88. Retaining the directory structure `$GOPATH/src/github.com/influxdata` is necessary so that Go imports work correctly.
  89. Build and Test
  90. -----
  91. Make sure you have Go installed and the project structure as shown above. To then get the dependencies for the project, execute the following commands:
  92. ```bash
  93. cd $GOPATH/src/github.com/influxdata/influxdb
  94. gdm restore
  95. ```
  96. To then build and install the binaries, run the following command.
  97. ```bash
  98. go clean ./...
  99. go install ./...
  100. ```
  101. The binaries will be located in `$GOPATH/bin`. Please note that the InfluxDB binary is named `influxd`, not `influxdb`.
  102. To set the version and commit flags during the build pass the following to the **install** command:
  103. ```bash
  104. -ldflags="-X main.version=$VERSION -X main.branch=$BRANCH -X main.commit=$COMMIT"
  105. ```
  106. where `$VERSION` is the version, `$BRANCH` is the branch, and `$COMMIT` is the git commit hash.
  107. If you want to build packages, see `build.py` usage information:
  108. ```bash
  109. python build.py --help
  110. # Or to build a package for your current system
  111. python build.py --package
  112. ```
  113. To run the tests, execute the following command:
  114. ```bash
  115. cd $GOPATH/src/github.com/influxdata/influxdb
  116. go test -v ./...
  117. # run tests that match some pattern
  118. go test -run=TestDatabase . -v
  119. # run tests and show coverage
  120. go test -coverprofile /tmp/cover . && go tool cover -html /tmp/cover
  121. ```
  122. To install go cover, run the following command:
  123. ```
  124. go get golang.org/x/tools/cmd/cover
  125. ```
  126. Generated Google Protobuf code
  127. -----------------
  128. Most changes to the source do not require that the generated protocol buffer code be changed. But if you need to modify the protocol buffer code, you'll first need to install the protocol buffers toolchain.
  129. First install the [protocol buffer compiler](https://developers.google.com/protocol-buffers/
  130. ) 2.6.1 or later for your OS:
  131. Then install the go plugins:
  132. ```bash
  133. go get github.com/gogo/protobuf/proto
  134. go get github.com/gogo/protobuf/protoc-gen-gogo
  135. go get github.com/gogo/protobuf/gogoproto
  136. ```
  137. Finally run, `go generate` after updating any `*.proto` file:
  138. ```bash
  139. go generate ./...
  140. ```
  141. **Troubleshooting**
  142. If generating the protobuf code is failing for you, check each of the following:
  143. * Ensure the protobuf library can be found. Make sure that `LD_LIBRRARY_PATH` includes the directory in which the library `libprotoc.so` has been installed.
  144. * Ensure the command `protoc-gen-gogo`, found in `GOPATH/bin`, is on your path. This can be done by adding `GOPATH/bin` to `PATH`.
  145. Generated Go Templates
  146. ----------------------
  147. The query engine requires optimizes data structures for each data type so
  148. instead of writing each implementation several times we use templates. _Do not
  149. change code that ends in a `.gen.go` extension!_ Instead you must edit the
  150. `.gen.go.tmpl` file that was used to generate it.
  151. Once you've edited the template file, you'll need the [`tmpl`][tmpl] utility
  152. to generate the code:
  153. ```sh
  154. $ go get github.com/benbjohnson/tmpl
  155. ```
  156. Then you can regenerate all templates in the project:
  157. ```sh
  158. $ go generate ./...
  159. ```
  160. [tmpl]: https://github.com/benbjohnson/tmpl
  161. Pre-commit checks
  162. -------------
  163. We have a pre-commit hook to make sure code is formatted properly and vetted before you commit any changes. We strongly recommend using the pre-commit hook to guard against accidentally committing unformatted code. To use the pre-commit hook, run the following:
  164. ```bash
  165. cd $GOPATH/src/github.com/influxdata/influxdb
  166. cp .hooks/pre-commit .git/hooks/
  167. ```
  168. In case the commit is rejected because it's not formatted you can run
  169. the following to format the code:
  170. ```
  171. go fmt ./...
  172. go vet ./...
  173. ```
  174. To install go vet, run the following command:
  175. ```
  176. go get golang.org/x/tools/cmd/vet
  177. ```
  178. NOTE: If you have not installed mercurial, the above command will fail. See [Revision Control Systems](#revision-control-systems) above.
  179. For more information on `go vet`, [read the GoDoc](https://godoc.org/golang.org/x/tools/cmd/vet).
  180. Profiling
  181. -----
  182. When troubleshooting problems with CPU or memory the Go toolchain can be helpful. You can start InfluxDB with CPU and memory profiling turned on. For example:
  183. ```sh
  184. # start influx with profiling
  185. ./influxd -cpuprofile influxdcpu.prof -memprof influxdmem.prof
  186. # run queries, writes, whatever you're testing
  187. # Quit out of influxd and influxd.prof will then be written.
  188. # open up pprof to examine the profiling data.
  189. go tool pprof ./influxd influxd.prof
  190. # once inside run "web", opens up browser with the CPU graph
  191. # can also run "web <function name>" to zoom in. Or "list <function name>" to see specific lines
  192. ```
  193. Note that when you pass the binary to `go tool pprof` *you must specify the path to the binary*.
  194. If you are profiling benchmarks built with the `testing` package, you may wish
  195. to use the [`github.com/pkg/profile`](github.com/pkg/profile) package to limit
  196. the code being profiled:
  197. ```go
  198. func BenchmarkSomething(b *testing.B) {
  199. // do something intensive like fill database with data...
  200. defer profile.Start(profile.ProfilePath("/tmp"), profile.MemProfile).Stop()
  201. // do something that you want to profile...
  202. }
  203. ```
  204. Continuous Integration testing
  205. -----
  206. InfluxDB uses CircleCI for continuous integration testing. To see how the code is built and tested, check out [this file](https://github.com/influxdata/influxdb/blob/master/circle-test.sh). It closely follows the build and test process outlined above. You can see the exact version of Go InfluxDB uses for testing by consulting that file.