Commit 0716064b authored by Christopher Ferris's avatar Christopher Ferris
Browse files

transfer from GitHub hyperledger/fabric

Copied from commit sha 346f9fb448140e931fed73b46f528de6dacbc0d0
to Gerrit. Verified that all DCO signoff received or IBM

Change-Id: I812a2f48382a3cd37e153cd056d0ea94b7f416a0
Signed-off-by: default avatarChristopher Ferris <>
parent a0f4c0d0
*.sh text eol=lf
*.go text eol=lf
*.yaml text eol=lf
*.yml text eol=lf
*.md text eol=lf
*.json text eol=lf
*.proto text eol=lf
*.py text eol=lf
*.js text eol=lf
*.txt text eol=lf
LICENSE text eol=lf
<!-- For general purpose questions, use Stack Overflow -->
## Description
<!-- Describe your issue or user story in detail -->
## Describe How to Reproduce
<!-- If an issue, provide sufficient context and steps to reproduce the issue -->
<!-- Provide a general summary of your changes in the Title above -->
## Description
<!-- Describe your changes in detail. -->
## Motivation and Context
<!-- Why is this change required? What problem does it solve? -->
<!-- If it fixes an open issue, please link to the issue here. -->
Fixes #
## How Has This Been Tested?
<!-- If this PR does not contain a new test case, explain why. -->
<!-- Describe in detail how you tested your changes. -->
## Checklist:
<!-- To check a box, and an 'x': [x] -->
<!-- To uncheck box, add a space: [ ] -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [] I have added a [Signed-off-by](
- [] I have either added documentation to cover my changes or this change requires no new documentation.
- [] I have either added unit tests to cover my changes or this change requires no new tests.
- [] I have run [golint]( and have fixed valid warnings in code I have added or modified. This tool generates false positives so you may choose to ignore some warnings. The goal is clean, consistent, and readable code.
<!-- The continuous integration build process will run [make checks]( to confirm that tests pass and that code quality meets minimum standards. You may optionally run this locally as PRs will not be accepted until they pass. -->
# Local build binaries
# Emacs backup files
# bddtest log files
# bddtest coverage files
# Makefile dummy artifacts
# go-carpet output files
# make node-sdk copied files
language: go
- 1.6
sudo: required
- docker
- TEST_TARGET=unit-test
- TEST_TARGET=behave
- echo "Starting Docker Daemon "
- |
USER_NAME="$(echo $GIT_USER | cut -d '/' -f 1)" && REPO_NAME="$(echo $GIT_USER | cut -d '/' -f 2)"
ip="$(ifconfig docker0 | grep "inet addr:" | awk '{print $2}' | cut -d ':' -f 2)"
port="$(ps -ef | grep docker | awk '{print $11}' | cut -d ':' -f 3)"
sudo stop docker
sudo docker daemon -H tcp://$port -H unix:///var/run/docker.sock >> dockerlogfile.log 2>&1 &
- |
cd $HOME/gopath/src/$USER_NAME/$REPO_NAME/scripts/provision/ && chmod +x && sudo ./
echo " Installing Rocks DB, g++ compilers & Dependencies "
sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test && sudo apt-get -qq update && sudo apt-get -qq install g++-4.8 && sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 90
sudo apt-get install build-essential -y
sudo apt-get install -y libsnappy-dev zlib1g-dev libbz2-dev
cd /tmp
git clone --branch v4.1 --single-branch --depth 1
cd rocksdb
make shared_lib
sudo INSTALL_PATH=/usr/local make install-shared
sudo ldconfig
- cd $HOME/gopath/src/$USER_NAME/$REPO_NAME/scripts && chmod +x && ./ $TR_PULL_REQUEST $USER_NAME $REPO_NAME
- sudo rm -rf /var/hyperledger/ && sudo mkdir /var/hyperledger/ && sudo chown $USER:$USER /var/hyperledger
- cd /$HOME/gopath/src/
- make linter
- echo "Executing Tests"
- cd $HOME/gopath/src/
- sed -i -e 's/\b/'"$ip:$port"'/g' $HOME/gopath/src/
- export BEHAVE_OPTS="-D logs=Y -o testsummary.log" #Defined to both jobs.
- |
echo "Click below links to view behave container log files"
cd $HOME/gopath/src/
chmod +x scripts/
sudo ./scripts/
slack: 'hyperledgerproject:azMP8Mw3cfGigXkqi5RujZXr'
on_success: always
on_failure: always
### Welcome
We welcome contributions to the Hyperledger Project in many forms, and there's always plenty to do!
First things first, please review the Hyperledger Project's [Code of Conduct]( before participating. It is important that we keep things civil.
### Getting help
If you are looking for something to work on, or need some expert assistance in debugging a problem or working out a fix to an issue, our [community]( is always eager to help. We hang out on [Slack](, IRC (#hyperledger on and the [mailing lists]( Most of us don't bite ;-) and will be glad to help.
### Requirements and Use Cases
We have a [Requirements WG]( that is documenting use cases and from those use cases deriving requirements. If you are interested in contributing to this effort, please feel free to join the discussion in [slack](
### Reporting bugs
If you are a user and you find a bug, please submit an [issue]( Please try to provide sufficient information for someone else to reproduce the issue. One of the project's maintainers should respond to your issue within 24 hours. If not, please bump the issue and request that it be reviewed.
### Fixing issues and working stories
Review the [issues list]( and find something that interests you. You could also check the ["help wanted"]( list. It is wise to start with something relatively straight forward and achievable. Usually there will be a comment in the issue that indicates whether someone has already self-assigned the issue. If no one has already taken it, then add a comment assigning the issue to yourself, eg.: ```I'll work on this issue.```. Please be considerate and rescind the offer in comments if you cannot finish in a reasonable time, or add a comment saying that you are still actively working the issue if you need a little more time.
We are using the [GitHub Flow]( process to manage code contributions. If you are unfamiliar, please review that link before proceeding.
To work on something, whether a new feature or a bugfix:
1. Create a [fork]( (if you haven't already)
2. Clone it locally
git clone
3. Add the upstream repository as a remote
git remote add upstream
4. Create a branch
Create a descriptively-named branch off of your cloned fork ([more detail here](
cd fabric
git checkout -b issue-nnnn
5. Commit your code
Commit to that branch locally, and regularly push your work to the same branch on the server.
6. Commit messages
Commit messages must have a short description no longer than 50 characters followed by a blank line and a longer, more descriptive message that includes reference to issue(s) being addressed so that they will be automatically closed on a merge e.g. ```Closes #1234``` or ```Fixes #1234```.
7. Pull Request (PR)
**Note:** Each source file must include a license header for the Apache Software License 2.0. A template of that header can be found [here](
When you need feedback or help, or you think the branch is ready for merging, open a pull request (make sure you have first successfully built and tested with the [Unit and Behave Tests](docs/dev-setup/
_Note: if your PR does not merge cleanly, use ```git rebase master``` in your feature branch to update your pull request rather than using ```git merge master```_.
8. Did we mention tests? All code changes should be accompanied by new or modified tests.
9. Continuous Integration (CI): Be sure to check [Travis]( or the Slack [#fabric-ci-status]( channel for status of your build. You can re-trigger a build on [Jenkins]( with a PR comment containing `reverify jenkins`.
**Note:** While some underlying work to migrate the build system from Travis to Jenkins is taking place, you can ask the [maintainers]( to re-trigger a Travis build for your PR, either by adding a comment to the PR or on the [#fabric-ci-status]( Slack channel.
10. Any code changes that affect documentation should be accompanied by corresponding changes (or additions) to the documentation and tests. This will ensure that if the merged PR is reversed, all traces of the change will be reversed as well.
After your Pull Request (PR) has been reviewed and signed off, a maintainer will merge it into the master branch.
## Coding guidelines
### Coding Golang <a name="coding-go"></a>
- We code in Go&trade; and strictly follow the [best practices](
and will not accept any deviations. You must run the following tools against your Go code and fix all errors and warnings:
- [golint](
- [go vet](
- [goimports](
## Generating gRPC code <a name="gRPC"></a>
If you modify any `.proto` files, run the following command to generate/update the respective `.pb.go` files.
cd $GOPATH/src/
make protos
## Adding or updating Go packages <a name="vendoring"></a>
The Hyperledger Fabric Project uses Go 1.6 vendoring for package management. This means that all required packages reside in the `vendor` folder within the fabric project. Go will use packages in this folder instead of the GOPATH when the `go install` or `go build` commands are executed. To manage the packages in the `vendor` folder, we use [Govendor](, which is installed in the Vagrant environment. The following commands can be used for package management:
# Add external packages.
govendor add +external
# Add a specific package.
govendor add
# Update vendor packages.
govendor update +vendor
# Revert back to normal GOPATH packages.
govendor remove +vendor
# List package.
govendor list
### Becoming a maintainer
This project is managed under open governance model as described in our [charter]( Projects or sub-projects will be lead by a set of maintainers. New projects can designate an initial set of maintainers that will be approved by the Technical Steering Committee when the project is first approved. The project's maintainers will, from time-to-time, consider adding a new maintainer. An existing maintainer will post a pull request to the [MAINTAINERS.txt](MAINTAINERS.txt) file. If a majority of the maintainers concur in the comments, the pull request is then merged and the individual becomes a maintainer.
### Legal stuff
**Note:** Each source file must include a license header for the Apache Software License 2.0. A template of that header can be found [here](
We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the same approach&mdash;the [Developer's Certificate of Origin 1.1 (DCO)](docs/biz/DCO1.1.txt)&mdash;that the Linux&reg; Kernel [community]( uses to manage code contributions.
We simply ask that when submitting a pull request, the developer must include a sign-off statement in the pull request description.
Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
Signed-off-by: John Doe <>
Apache License
Version 2.0, January 2004
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
implied, including, without limitation, any warranties or conditions
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "{}"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright {yyyy} {name of copyright owner}
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
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.
Binh Nguyen binhn
Sheehan Anderson srderson
Tamas Blummer tamasblummer
Robert Fajta rfajta
Greg Haskins ghaskins
Jonathan Levi JonathanLevi
Gabor Hosszu gabre
Simon Schubert corecode
Chris Ferris christo4ferris
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership. The ASF licenses this file
# to you 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
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# KIND, either express or implied. See the License for the
# specific language governing permissions and limitations
# under the License.
# -------------------------------------------------------------
# This makefile defines the following targets
# - all (default) - builds all targets and runs all tests/checks
# - checks - runs all tests/checks
# - peer - builds the fabric peer binary
# - membersrvc - builds the membersrvc binary
# - unit-test - runs the go-test based unit tests
# - behave - runs the behave test
# - behave-deps - ensures pre-requisites are availble for running behave manually
# - gotools - installs go tools like golint
# - linter - runs all code checks
# - images[-clean] - ensures all docker images are available[/cleaned]
# - peer-image[-clean] - ensures the peer-image is available[/cleaned] (for behave, etc)
# - membersrvc-image[-clean] - ensures the membersrvc-image is available[/cleaned] (for behave, etc)
# - protos - generate all protobuf artifacts based on .proto files
# - node-sdk - builds the node.js client sdk
# - node-sdk-unit-tests - runs the node.js client sdk unit tests
# - clean - cleans the build area
# - dist-clean - superset of 'clean' that also removes persistent state
CGO_FLAGS = CGO_CFLAGS=" " CGO_LDFLAGS="-lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy"
UID = $(shell id -u)
EXECUTABLES = go docker git
K := $(foreach exec,$(EXECUTABLES),\
$(if $(shell which $(exec)),some string,$(error "No $(exec) in PATH: Check dependencies")))
# SUBDIRS are components that have their own Makefiles that we can invoke
SUBDIRS = gotools sdk/node
SUBDIRS:=$(strip $(SUBDIRS))
# Make our baseimage depend on any changes to images/base or scripts/provision
BASEIMAGE_RELEASE = $(shell cat ./images/base/release)
BASEIMAGE_DEPS = $(shell git ls-files images/base scripts/provision)
PROJECT_FILES = $(shell git ls-files)
IMAGES = base src ccenv peer membersrvc
all: peer membersrvc checks
checks: linter unit-test behave
cd $@ && $(MAKE)
.PHONY: peer
peer: build/bin/peer
peer-image: build/image/peer/.dummy
.PHONY: membersrvc
membersrvc: build/bin/membersrvc
membersrvc-image: build/image/membersrvc/.dummy
unit-test: peer-image gotools
.PHONY: images
images: $(patsubst %,build/image/%/.dummy, $(IMAGES))
behave-deps: images peer
behave: behave-deps
@echo "Running behave tests"
@cd bddtests; behave $(BEHAVE_OPTS)
linter: gotools
@echo "LINT: Running code checks.."
@echo "Running go vet"
go vet ./consensus/...
go vet ./core/...
go vet ./events/...
go vet ./examples/...
go vet ./membersrvc/...
go vet ./peer/...
go vet ./protos/...
@echo "Running goimports"
# We (re)build protoc-gen-go from within docker context so that
# we may later inject the binary into a different docker environment
# This is necessary since we cannot guarantee that binaries built
# on the host natively will be compatible with the docker env.
%/bin/protoc-gen-go: build/image/base/.dummy Makefile
@echo "Building $@"
@mkdir -p $(@D)
@docker run -i \
--user=$(UID) \
-v $(abspath vendor/ \
-v $(abspath $(@D)):/opt/gopath/bin \
hyperledger/fabric-baseimage go install
@echo "Installing chaintool"
@cp devenv/tools/chaintool $@
# We (re)build a package within a docker context but persist the $GOPATH/pkg
# directory so that subsequent builds are faster
build/docker/bin/%: build/image/src/.dummy $(PROJECT_FILES)
$(eval TARGET = ${patsubst build/docker/bin/%,%,${@}})
@echo "Building $@"
@mkdir -p build/docker/bin build/docker/pkg
@docker run -i \
--user=$(UID) \
-v $(abspath build/docker/bin):/opt/gopath/bin \
-v $(abspath build/docker/pkg):/opt/gopath/pkg \
hyperledger/fabric-src go install$(TARGET)
mkdir -p $@
# Both peer and peer-image depend on ccenv-image
build/bin/peer: build/image/ccenv/.dummy
build/image/peer/.dummy: build/image/ccenv/.dummy
build/image/peer/.dummy: build/docker/bin/examples/events/block-listener/
build/bin/%: build/image/base/.dummy $(PROJECT_FILES)
@mkdir -p $(@D)
@echo "$@"
$(CGO_FLAGS) GOBIN=$(abspath $(@D)) go install $(PKGNAME)/$(@F)
@echo "Binary available as $@"
@touch $@
# Special override for base-image.
build/image/base/.dummy: $(BASEIMAGE_DEPS)
@echo "Building docker base-image"
@mkdir -p $(@D)
@./scripts/provision/ $(BASEIMAGE_RELEASE)
@touch $@
# Special override for src-image
build/image/src/.dummy: build/image/base/.dummy $(PROJECT_FILES)
@echo "Building docker src-image"
@mkdir -p $(@D)
@cat images/src/ > $(@D)/Dockerfile
@git ls-files | tar -jcT - > $(@D)/gopath.tar.bz2
docker build -t $(PROJECT_NAME)-src:latest $(@D)
@touch $@