Please note, that the only officially supported platform now is Linux. It's recommended to develop and deploy the App on Ubuntu 18.04 or Ubuntu 20.04.
-
Install Go as described at https://golang.org/doc/install
-
Ensure that the following line has been appended to
/etc/profile
:export PATH=$PATH:/usr/local/go/bin
-
Ensure that the following line has been appended to
~/.profile
:export PATH=$PATH:~/go/bin
-
-
Install Docker as described at https://docs.docker.com/engine/install/ubuntu/
-
In
Installation methods
section followInstall using the repository
method -
Check whether your user of Ubuntu has been added to
docker
group using the following command:getent group docker | awk -F: '{print $4}'
- If it has not been added, add it using
Manage Docker as a non-root user
section from https://docs.docker.com/engine/install/linux-postinstall/
- If it has not been added, add it using
-
-
Install Docker Compose as described at https://docs.docker.com/compose/install/
-
Building
make build make install
-
Run unit tests
make test
-
Run integration tests.
The integration tests are run against a local pool of nodes in Docker. REST integration tests need to have a backend running (CLI in REST mode).
The following script will start all necessary things and run all the tests:
./integration_tests/run-all.sh
If you want to run a particular group of tests (cli, light, rest), you can
./integration_tests/run-all.sh cli ./integration_tests/run-all.sh light ./integration_tests/run-all.sh rest ./integration_tests/run-all.sh cli,light
If you want to run a particular test you may:
./integration_tests/start-pool.sh bash <path-to-shell-script> # to run a cli test # OR go test <path-to-go-test-file> # to run REST or gRPC go test
-
Run deployment test
The deployment test verifies deployment steps described in docs/running-node.md.
./integration_tests/deploy/test_deploy.sh
The easiest way to run a local pool is to start it in Docker.
Validator nodes only (no Observers):
make install
make localnet_init
make localnet_start
Validator and Observer nodes:
make install
DCL_OBSERVERS=1 make localnet_init
make localnet_start
This will start a local pool of 4 validator nodes in Docker. The nodes will expose their RPC endpoints on ports 26657
, 26659
, 26661
, 26663
correspondingly.
Stopping the network:
make localnet_stop
Then you can start the network again with the existing data using make localnet_start
If you need to start a new clean network then run make localnet_rebuild
prior to executing make localnet_start
.
It will remove .dcl
directories from your user home directory (~
), remove .localnet
directory from the root directory of the cloned project,
and initialize a new network data using make localnet_init
.
Start a local pool as described above, and then just execute
dcld
Have a look at How To and transactions for instructions how to configure and use the CLI.
Start a local pool as described above.
Every node exposes a REST API at http://<node-host>:1317
(see https://docs.cosmos.network/v0.44/core/grpc_rest.html).
Have a look at transactions for a full list of REST endpoints.
Please take into account the following when sending a PR:
-
Make sure the new functionality has unit tests added
-
Make sure the new functionality has integration tests added
-
There is CI based on GitHub Actions that will do the following for every Pull Request:
- make sure the app can be built
- run go linter
- run unit tests
- run integration tests
- Use starport command to scaffold the module. Consider using a docker container built from the provided Dockerfile to have a predictable version of starport. See README.md.
- Have a look at the scripts and commands used for generation of existing modules and do it in a similar way (for example PKI module commands).
- Adjust the generated code
-
change the return value of
AppModule.ConsensusVersion
method to 1 inx/<module>/module.go
-
correct REST endpoints:
/dcl
instead of/zigbee-alliance/distributedcomplianceledger
inproto/<module>/query.proto
and in entries related to queries of the new module indocs/static/openapi.yml
-
add message validation as annotations (
validate
tags) inproto/<module>/tx.proto
-
add
(cosmos_proto.scalar) = "cosmos.AddressString"
annotation for all fields with address/account type (such assigner
orowner
). -
fix types if needed in
proto/<module>/<entity>.proto
files- Note1:
unit64
will be returned as string if the output is a JSON format. So, it's better to useuint64
only when it's reallyuint64
. - Note2: for
uint16
type: useint32
during starport scaffolding, and add custom validation (annotations above) to check the lower and upper bounds. - Note3: for
uint32
type: useint32
during starport scaffolding, then replace it byuint32
in .proto files, re-generate the code and fix compilation errors.
- Note1:
-
build proto (for example
starport chain build
). Fix compilation errors if any. -
generate openapi docs from proto using (
scripts/dcl-swagger-gen.sh
). recommended to run from container built from Dockerfile -
Note1: colons (
:
) are part of subject-id in PKI module, but colons are not allowed in gRPC REST URLs by default.allow_colon_final_segments=true
should be used as a workaround. So, make sure thatruntime.AssumeColonVerbOpt(false)
in/x/pki/types/query.pb.gw.go
. It's usually sufficient to revert the generated changes in/x/pki/types/query.pb.gw.go
.
-
- Call
validator.Validate(msg)
inValidateBasic
methods for all generated messages - Implement business logic in
msg_server_xxx.go
- Improve
NotFound
error processing:- replace
status.Error(codes.InvalidArgument, "not found")
tostatus.Error(codes.NotFound, "not found")
in every generatedgrpc_query_xxx.go
to return 404 error in REST.
- replace
- Support state proof for single value queries in CLI:
- use
cli.QueryWithProof
instead of cosmos queries that doesn't support state proofs - add proper handling for list queries and write requests when used with a light client proxy
(see
IsWriteInsteadReadRpcError
andIsKeyNotFoundRpcError
)
- use
- Add unit tests (see other modules for reference)
- Add CLI-based integration tests to
integration_tests/cli/<module>
(see other modules for reference) - Add gRPC/REST-based integration tests to
integration_tests/grpc_rest/<module>
(see other modules for reference)
- Use starport command to scaffold the module. Consider using the provided Dockerfile to have a predictable version of starport. See README.md.
- Never change
.pb
files manually. Do the changes in.proto
files. - Every time
.proto
files change, re-generate the code (for examplestarport chain build
) and fix compilation errors if any. - Update openapi docs from proto using (
scripts/dcl-swagger-gen.sh
). recommended to run from container built from Dockerfile - Note1: colons (
:
) are part of subject-id in PKI module, but colons are not allowed in gRPC REST URLs by default.allow_colon_final_segments=true
should be used as a workaround. So, make sure thatruntime.AssumeColonVerbOpt(false)
in/x/pki/types/query.pb.gw.go
. It's usually sufficient to revert the generated changes in/x/pki/types/query.pb.gw.go
.
Re-generate cosmos base openapi (service API from cosmos exposed in DCL) using cosmos-swagger-gen.sh from the project root:
- Consider using a docker container built from the provided Dockerfile to have a predictable version of swagger
./scripts/cosmos-swagger-gen.sh base
./scripts/cosmos-swagger-gen.sh tx
Please note, that we depend on the Tendermint fork https://github.com/zigbee-alliance/tendermint/releases/tag/v0.34.140 due to hotfixes for tendermint/tendermint#7640 and tendermint/tendermint#7641 required for Light Client Proxy. Now that fixes are merged to Tendermint master, so check if we still need to depend on the fork.
Also don't forget to update the link to the Tendermint RPC in Swagger UI.
For more details, please have a look at Cosmos SDK tutorial.