This removes a bunch of outdated info from the developer guide and wraps
the text so it's easier to edit. govendor instructions are gone because we now
use Go modules for that. The 'Contributing' section is moved to the top.
**NOTE: These instructions are for people who want to contribute Go source code changes.
**NOTE: These instructions are for people who want to contribute Go source code changes.
If you just want to run ethereum, use the normal [Installation Instructions](../install-and-build/installing-geth)**
If you just want to run ethereum, use the regular [Installation Instructions][install-guide].**
This document is the entry point for developers of the Go implementation of Ethereum. Developers here refer to the hands-on: who are interested in build, develop, debug, submit a bug report or pull request or contribute code to go-ethereum.
This document is the entry point for developers of the Go implementation of Ethereum.
Developers here refer to the hands-on: who are interested in build, develop, debug, submit
a bug report or pull request or contribute code to go-ethereum.
## Building and Testing
## Contributing
### Go Environment
We assume that you have [`go` installed](https://golang.org/doc/install), and `GOPATH` is set.
**Note**:You must have your working copy under `$GOPATH/src/github.com/ethereum/go-ethereum`.
Thank you for considering to help out with the source code! We welcome contributions from
anyone on the internet, and are grateful for even the smallest of fixes!
Since `go` does not use relative path for import, working in any other directory will have no effect, since the import paths will be appended to `$GOPATH/src`, and if the lib does not exist, the version at master HEAD will be downloaded.
GitHub is used to track issues and contribute code, suggestions, feature requests or
documentation.
Most likely you will be working from your fork of `go-ethereum`, let's say from `github.com/nirname/go-ethereum`. Clone or move your fork into the right place:
If you'd like to contribute to go-ethereum, please fork, fix, commit and send a pull
request (PR) for the maintainers to review and merge into the main code base. If you wish
to submit more complex changes though, please check up with the core devs in the
go-ethereum [Discord Server][discord]. to ensure those changes are in line with the
general philosophy of the project and/or get some early feedback. This can reduce your
effort as well as speeding up our review and merge procedures.
```
PRs need to be based on and opened against the `master` branch (unless by explicit
To make life easier try [git flow](http://nvie.com/posts/a-successful-git-branching-model/) it sets this all up and streamlines your work flow.
### Testing
### Testing
Testing one library:
Testing a package:
```
```
go test -v -cpu 4 ./eth
go test -v ./eth
```
```
Using options `-cpu` (number of cores allowed) and `-v` (logging even if no error) is recommended.
Running an individual test:
Testing only some methods:
```
```
go test -v -cpu 4 ./eth -run TestMethod
go test -v ./eth -run TestMethod
```
```
**Note**: here all tests with prefix _TestMethod_ will be run, so if you got TestMethod, TestMethod1, then both!
**Note**: here all tests with prefix _TestMethod_ will be run, so if you got TestMethod,
TestMethod1, then both tests will run.
Running benchmarks, eg.:
Running benchmarks, eg.:
```
```
go test -v -cpu 4 -bench . -run BenchmarkJoin
go test -v -bench . -run BenchmarkJoin
```
```
for more see [go test flags](http://golang.org/cmd/go/#hdr-Description_of_testing_flags)
For more information, see the [go test flags][testflag] documentation.
### Metrics and monitoring
`geth` can do node behaviour monitoring, aggregation and show performance metric charts.
read about [metrics and monitoring](../doc/metrics-and-monitoring)
### Getting Stack Traces
### Getting Stack Traces
If `geth` is started with the `--pprof` option, a debugging HTTP server is made available on port 6060. You can bring up http://localhost:6060/debug/pprof to see the heap, running routines etc. By clicking full goroutine stack dump (clicking http://localhost:6060/debug/pprof/goroutine?debug=2) you can generate trace that is useful for debugging.
If `geth` is started with the `--pprof` option, a debugging HTTP server is made available
on port 6060. You can bring up <http://localhost:6060/debug/pprof> to see the heap,
running routines etc. By clicking "full goroutine stack dump" you can generate a trace
that is useful for debugging.
Note that if you run multiple instances of `geth`, this port will only work for the first instance that was launched. If you want to generate stacktraces for these other instances, you need to start them up choosing an alternative pprof port. Make sure you are redirecting stderr to a logfile.
Note that if you run multiple instances of `geth`, this port will only work for the first
instance that was launched. If you want to generate stacktraces for these other instances,
you need to start them up choosing an alternative pprof port. Make sure you are
Alternatively if you want to kill the clients (in case they hang or stalled syncing, etc) but have the stacktrace too, you can use the `-QUIT` signal with `kill`:
Alternatively if you want to kill the clients (in case they hang or stalled syncing, etc)
and have the stacktrace too, you can use the `-QUIT` signal with `kill`:
```
```
killall -QUIT geth
killall -QUIT geth
@ -108,36 +113,10 @@ killall -QUIT geth
This will dump stack traces for each instance to their respective log file.
This will dump stack traces for each instance to their respective log file.
Felix Lange
5 years ago
committed by
GitHub