This repository contains blockchain Oracles used by Sweetbridge project.
Unless you are using docker environment to build the applications (explained below) you have to set-up the following environment:
go >= 1.7and
make. Make sure that
goexecutable is in your
- For static compilation:
- Make sure
go env GOPATH) is part of your
- Make sure you have an access to the oracles repository.
Clone this repository into your
go env). Install dependencies:
go get(this will work only if the repo is open) and hack the git config a bit: https://gist.github.com/shurcooL/6927554
Please refer to
setup-quickstart.sh if you want to install it on debian / ubuntu.
This is not required for building application, but required for proper development.
make setup-dev install-deps
- DB model is defined in the model repository.
Whenever you want to sync dependencies (so if you don't follow the development process) you have to make sure that everything is synced. However if you are sure that you don't need it, or you are just repeating builds you can skip it.
# skip the first step if you don't need to sync dependencies make install-deps make build
The executables are stored in the
Furthermore there are handy application specific jobs (to build only a single application). To do that just look at one of
make build- jobs.
Again, for CI, and release to make sure that dependencies are always synced. The simple spell to build for release is:
make install-deps build
Building using Docker
We provide consistent environment to build the applications using Docker containers. Everything is wrapped in the make jobs. Firstly you need to build the image. This is suppose to be done only once:
Next, whenever you want to build the applications:
NOTE: For docker build we are using Alpine Linux. This allows is compatible for putting the binaries in a tiny Alpine container. However to run the same binary in other distributions (Fedora, Ubuntu, OpenSUSE) you will need to use
musl (which is using by Alpine during linking).
Building using Docker compatible with AWS Linux
For the reasons explained above, the alpine based builds are not working with Debian or Red Hat based distributions. To overcome this we provide alternative docker builders which produce compatible binaries.
The procedure is similar to the one above - just use builder commands with
-debian suffix, eg:
All applications are build from the main packages in the
cmd/ sub-directories. Each package contains the README.md file with the application description.
All applications are compiled into self-contained binaries (no external dependencies needed except the compatible libc version). Each application support the help argument to display the usage description - please use it to find more information about required and optional parameters:
All applications are using structured log15 logger. Logger is configured by default to construct colored output, which is helpful when printing the logs to the screen or storying in the system journal. However when redirecting the output to the file it's better to disable the colored output. We can configure logger with the following options:
-log-colored=false- disable the colored output
Common ethereum parameters
Oracles share the following, ethereum-specific obligatory parameters:
-pk-hex-- a plaintext hex-encoded private key.
-pk-pwd-- a JSON encrypted private key. Required if the
-pk-hexis not specified.
-eth-network-- a network name which oracles is connecting to (use
-hto list all network names).
-eth-network-file-- a JSON file describing Ethereum networks. It's compatible with
networksTruffle file section.
-contracts-- the path to the directory containing contract schemas. The contracts have to be deployed on the network before using them, and each schema used by the application have to have contract address (per network) written in. Furthermore the address in schema has to reflect the contract version described by the schema. Shortly speaking: don't manipulate the schemas unless you know what are you doing. Usually the schema in
submodules/contract-deployments/backstage/reflect to the working contracts deployed on the backstage.
All applications should have defined following parameters:
SB_ENV- environment variable specifying stage (eg: production, backstage, testing ...)
-rollbar- flag with rollbar token. Has to be specified.
For production release, the command line parameters are specified using environment variables. This are translated to the command line flags using the wrapper shell scripts in the
scripts/abigen.js is used to generate Go interfaces based on JSON interface file produced by Truffle. Whenever new contracts are provided you should regenerate Go interfaces
node scripts/abigen.js <path to the truffle contract builds>
Usually it's enough to use