mirror of https://github.com/hashicorp/consul
Browse Source
* Add a contribution guide and link to it from readme * Add first pass at testing section for contribution guide * Format as in README.md * Add responding to community questions as way to contributepull/4760/head
Freddy
6 years ago
committed by
Jack Pearkes
2 changed files with 148 additions and 31 deletions
@ -0,0 +1,146 @@
|
||||
# Contributing to Consul |
||||
>**Note:** We take Consul's security and our users' trust very seriously. |
||||
>If you believe you have found a security issue in Consul, please responsibly |
||||
>disclose by contacting us at security@hashicorp.com. |
||||
|
||||
**First:** if you're unsure or afraid of _anything_, just ask or submit the |
||||
issue or pull request anyways. You won't be yelled at for giving your best |
||||
effort. The worst that can happen is that you'll be politely asked to change |
||||
something. We appreciate any sort of contributions, and don't want a wall of |
||||
rules to get in the way of that. |
||||
|
||||
That said, if you want to ensure that a pull request is likely to be merged, |
||||
talk to us! A great way to do this is in issues themselves. When you want to |
||||
work on an issue, comment on it first and tell us the approach you want to take. |
||||
|
||||
## Getting Started |
||||
### Some Ways to Contribute |
||||
* Report potential bugs. |
||||
* Suggest product enhancements. |
||||
* Increase our test coverage. |
||||
* Fix a [bug](https://github.com/hashicorp/consul/labels/bug). |
||||
* Implement a requested [enhancement](https://github.com/hashicorp/consul/labels/enhancement). |
||||
* Improve our guides and documentation. Consul's [Guides](https://www.consul.io/docs/guides/index.html), [Docs](https://www.consul.io/docs/index.html), and [api godoc](https://godoc.org/github.com/hashicorp/consul/api) |
||||
are deployed from this repo. |
||||
* Respond to questions about usage on the issue tracker or mailing list. |
||||
|
||||
### Reporting an Issue: |
||||
>Note: Issues on GitHub for Consul are intended to be related to bugs or feature requests. |
||||
>Questions should be directed to other community resources such as the: [Mailing List](https://groups.google.com/group/consul-tool/), [FAQ](https://www.consul.io/docs/faq.html), or [Guides](https://www.consul.io/docs/guides/index.html). |
||||
|
||||
* Make sure you test against the latest released version. It is possible we |
||||
already fixed the bug you're experiencing. However, if you are on an older |
||||
version of Consul and feel the issue is critical, do let us know. |
||||
|
||||
* Check existing issues (both open and closed) to make sure it has not been |
||||
reported previously. |
||||
|
||||
* Provide a reproducible test case. If a contributor can't reproduce an issue, |
||||
then it dramatically lowers the chances it'll get fixed. |
||||
|
||||
* Aim to respond promptly to any questions made by the Consul team on your |
||||
issue. Stale issues will be closed. |
||||
|
||||
### Issue Lifecycle |
||||
|
||||
1. The issue is reported. |
||||
|
||||
2. The issue is verified and categorized by a Consul maintainer. |
||||
Categorization is done via tags. For example, bugs are tagged as "bug". |
||||
|
||||
3. Unless it is critical, the issue is left for a period of time (sometimes many |
||||
weeks), giving outside contributors a chance to address the issue. |
||||
|
||||
4. The issue is addressed in a pull request or commit. The issue will be |
||||
referenced in the commit message so that the code that fixes it is clearly |
||||
linked. |
||||
|
||||
5. The issue is closed. |
||||
|
||||
## Building Consul |
||||
|
||||
If you wish to work on Consul itself, you'll first need [Go](https://golang.org) |
||||
installed (version 1.10+ is _required_). Make sure you have Go properly installed, |
||||
including setting up your [GOPATH](https://golang.org/doc/code.html#GOPATH). |
||||
|
||||
Next, clone this repository into `$GOPATH/src/github.com/hashicorp/consul` and |
||||
then run `make dev`. In a few moments, you'll have a working `consul` executable |
||||
in `consul/bin` and `$GOPATH/bin`: |
||||
|
||||
>Note: `make dev` will build for your local machine's os/architecture. If you wish to build for all os/architecture combinations use `make`. |
||||
|
||||
## Making Changes to Consul |
||||
|
||||
The first step to making changes is to fork Consul. Afterwards, the easiest way |
||||
to work on the fork is to set it as a remote of the Consul project: |
||||
|
||||
1. Navigate to `$GOPATH/src/github.com/hashicorp/consul` |
||||
2. Rename the existing remote's name: `git remote rename origin upstream`. |
||||
3. Add your fork as a remote by running |
||||
`git remote add origin <github url of fork>`. For example: |
||||
`git remote add origin https://github.com/myusername/consul`. |
||||
4. Checkout a feature branch: `git checkout -t -b new-feature` |
||||
5. Make changes |
||||
6. Push changes to the fork when ready to submit PR: |
||||
`git push -u origin new-feature` |
||||
|
||||
By following these steps you can push to your fork to create a PR, but the code on disk still |
||||
lives in the spot where the go cli tools are expecting to find it. |
||||
|
||||
>Note: If you make any changes to the code, run `make format` to automatically format the code according to Go standards. |
||||
|
||||
## Testing |
||||
|
||||
Before submitting changes, run **all** tests locally by typing `make test`. |
||||
The test suite may fail if over-parallelized, so if you are seeing stochastic |
||||
failures try `GOTEST_FLAGS="-p 2 -parallel 2" make test`. |
||||
|
||||
Certain testing patterns such as creating a test `Client` in the `api` pkg |
||||
or a `TestAgent` followed by a session can lead to flaky tests. More generally, |
||||
any tests with components that rely on readiness of other components are often |
||||
flaky. |
||||
|
||||
Our makefile has some tooling built in to help validate the stability of single |
||||
or package-wide tests. By running the `test-flake` goal we spin up a local docker |
||||
container that mirrors a CPU constrained version of our CI environment. Here we can |
||||
surface uncommon failures that are typically hard to reproduce by re-running |
||||
tests multiple times. |
||||
|
||||
The makefile goal accepts the following variables as arguments: |
||||
|
||||
* **FLAKE_PKG** Target package (required) |
||||
|
||||
* **FLAKE_TEST** Target test |
||||
|
||||
* **FLAKE_CPUS** Amount of CPU resources for container |
||||
|
||||
* **FLAKE_N** Number of times to run tests |
||||
|
||||
Examples: |
||||
`make test-flake FLAKE_PKG=connect/proxy` |
||||
`make test-flake FLAKE_PKG=connect/proxy FLAKE_TEST=TestUpstreamListener` |
||||
`make test-flake FLAKE_PKG=connect/proxy FLAKE_TEST=TestUpstreamListener FLAKE_CPUS=0.15 FLAKE_N=30` |
||||
|
||||
The underlying script dumps the full Consul log output to `test.log` in |
||||
the directory of the target package. In the example above it would be |
||||
located at `consul/connect/proxy/test.log`. |
||||
|
||||
Historically, the defaults for `FLAKE_CPUS` (30) and `FLAKE_N` (0.15) have been |
||||
sufficient to surface a flaky test. If a test is run in this environment and |
||||
it does not fail after 30 iterations, it should be sufficiently stable. |
||||
|
||||
## Vendoring |
||||
|
||||
Consul currently uses [govendor](https://github.com/kardianos/govendor) for |
||||
vendoring and [vendorfmt](https://github.com/magiconair/vendorfmt) for formatting |
||||
`vendor.json` to a more merge-friendly "one line per package" format. |
||||
|
||||
If you are submitting a change that requires new or updated dependencies, |
||||
please include them in `vendor/vendor.json` and in the `vendor/` folder. |
||||
This helps everything get tested properly in CI. |
||||
|
||||
Use `govendor fetch <project>` to add a project as a dependency. See govendor's [Quick Start](https://github.com/kardianos/govendor#quick-start-also-see-the-faq) for examples. |
||||
|
||||
Please only apply the minimal vendor changes to get your PR to work. |
||||
Consul does not attempt to track the latest version for each dependency. |
||||
|
Loading…
Reference in new issue