We keep our development process fairly simple and enforce any hard rules through automation.
Before beginning, please familiarize yourself with these documents:
These are the basic things to consider when contributing to the project:
masterbranch is the main development branch of the Zilliqa repository. All new work must be created on a new branch off of the
- When compiling code changes, use
./build.sh styleinstead of just
./build.shin order for clang-format to automatically fix the code formatting.
- Write or perform any tests for your code changes. The different supported tests are described in the section below.
- When submitting a pull request, fill in the details requested in the template.
CI/CD Pipeline and Release Management
Pull requests must get approval from at least 2 reviewers before they can be merged into the
Additionally, pull requests must pass the automated checks on the code changes. These are done by Travis CI build jobs along both the branch and the merge with
master. These checks include:
- Code build
- Code coverage
New releases are periodically created, and these can be accessed by checking out release tags (e.g.,
git checkout tags/v6.2.0).
These releases are accompanied by release notes detailing the fixes, improvements, and any new features.
Releases are also automatically made available as Docker images on our Docker Hub repository. Node operators who are not on our officially supported operating systems may choose to run their nodes on these images instead.
There are several ways to test out the core protocol:
- Writing unit tests targeted at specific parts of the code. Most unit tests are executed as part of the CI/CD pipeline to ensure non-regression.
- Booting up a local testnet to simulate the Zilliqa network on a local machine.
- Launching a cloud-based testnet that approximates the actual Zilliqa Mainnet. Currently this method is available only to the Zilliqa Research team. Please coordinate with the team should your code changes require testing using this method.