We'd love your help!
Jaeger is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted.
We gratefully welcome improvements to documentation as well as to code.
By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the DCO file for details.
This library uses glide to manage dependencies.
To get started, make sure you clone the Git repository into the correct location github.com/jaegertracing/jaeger
relative to $GOPATH
:
mkdir -p $GOPATH/src/github.com/jaegertracing
cd $GOPATH/src/github.com/jaegertracing
git clone git@github.com:jaegertracing/jaeger.git jaeger
cd jaeger
Then install dependencies and run the tests:
git submodule update --init --recursive
glide install
make test
The jaeger-ui
submodule contains the source code for the UI assets (requires Node.js 6+). The assets must be compiled first with make build_ui
, which runs Node.js build and then packages the assets into a Go file that is .gitignore
-ed. The packaged assets can be enabled by providing a build tag ui
, e.g.:
$ go run -tags ui ./cmd/standalone/main.go
Alternatively, the path to the built UI assets can be provided via --query.static-files
flag:
$ go run ./cmd/standalone/main.go --query.static-files jaeger-ui/build
These are general guidelines on how to organize source code in this repository.
github.com/jaegertracing/jaeger
cmd/ - All binaries go here
agent/
app/ - The actual code for the binary
main.go
collector/
app/ - The actual code for the binary
main.go
crossdock/ - Cross-repo integration test configuration
docs/ - Documentation
examples/
hotrod/ - Demo application that uses OpenTracing API
idl/ - (submodule) https://github.com/jaegertracing/jaeger-idl
jaeger-ui/ - (submodule) https://github.com/jaegertracing/jaeger-ui
model/ - Where models are kept, e.g. Process, Span, Trace
pkg/ - (See Note 1)
plugin/ - Swappable implementations of various components
storage/
cassandra/ - Cassandra implementations of storage APIs
. - Shared Cassandra stuff
spanstore/ - SpanReader / SpanWriter implementations
dependencystore/
elasticsearch/ - ES implementations of storage APIs
scripts/ - Miscellaneous project scripts, e.g. license update script
travis/ - Travis scripts called in .travis.yml
storage/
spanstore/ - SpanReader / SpanWriter interfaces
dependencystore/
thrift-gen/ - Generated Thrift types
agent/
jaeger/
sampling/
zipkincore/
glide.yaml - Glide is the project's dependency manager
mkdocs.yml - MkDocs builds the documentation in docs/
- Note 1:
pkg
is a collection of utility packages used by the Jaeger components without being specific to its internals. Utility packages are kept separate from the Jaeger core codebase to keep it as small and concise as possible. If some utilities grow larger and their APIs stabilize, they may be moved to their own repository, to facilitate re-use by other projects.
This projects follows the following pattern for grouping imports in Go files:
- imports from standard library
- imports from other projects
- imports from
jaeger
project
For example:
import (
"fmt"
"github.com/uber/jaeger-lib/metrics"
"go.uber.org/zap"
"github.com/jaegertracing/jaeger/cmd/agent/app"
"github.com/jaegertracing/jaeger/cmd/collector/app/builder"
)
Before making any significant changes, please open an issue. Discussing your proposed changes ahead of time will make the contribution process smooth for everyone.
Once we've discussed your changes and you've got your code ready, make sure
that tests are passing (make test
or make cover
) and open your PR. Your
pull request is most likely to be accepted if it:
- Includes tests for new functionality.
- Follows the guidelines in Effective Go and the Go team's common code review comments.
- Has a good commit message:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why instead of how
- Each commit must be signed by the author (see below).
By contributing your code, you agree to license your contribution under the terms of the Apache License.
If you are adding a new file it should have a header like below. The easiest
way to add such header is to run make fmt
.
// Copyright (c) 2017 The Jaeger Authors.
//
// 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.
The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the below (from developercertificate.org):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line to every git commit message:
Signed-off-by: Joe Smith <joe@gmail.com>
using your real name (sorry, no pseudonyms or anonymous contributions.)
You can add the sign off when creating the git commit via git commit -s
.
If you want this to be automatic you can set up some aliases:
git config --add alias.amend "commit -s --amend"
git config --add alias.c "commit -s"