Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Table of contents
Table of Contents | ||||
---|---|---|---|---|
|
Release distribution and management
Distributing releases
We use https://developer.rchain.coop, Github Releases, and Docker Hub to distribute our release packages.
Release archive
- Github releases - Contains an archive of all releases.
- Docker hub
- rchain/rnode:v0.#.# - Docker image of a tagged Github release
- rchain/rnode:latest - Docker image based on current state of master branch
- rchain/rnode:dev - Docker image based on current state of dev branch
Repositories under scope
As per the Github structure document, we build against the rchain repository.
Build branches and workflow
Build branches
We support continuous integration (CI) for the following branches:
- Dev branch
- Master branch
- Release branches
- Testing branch
Workflow
- Dev branch
- Update
- Test
- Build
- Generate Docker image (rchain/rnode:dev)
- Push of artifacts to binary repo
- Master branch
- Update
- Test
- Build
- Generate artifacts and Docker image (rchain/rnode:latest)
- Push of artifacts to binary repo
- Release branches (used as needed)
- Update
- Test
- Build
- Generate Docker image (rchain/rnode:<tag of release>)
- Push of artifacts to binary repo
- Testing branchbranch (used as needed)
- Update
- Test
- Build
- Generate Docker image (rchain/rnode:testing)
- Push of artifacts to binary repo
Distribution packages and docker images
Binary distribution packages from master, dev , testing, and release branches are automatically pushed to this repo: https://build.rchain-dev.tk.
Docker images automatically push from:
master (rchain/rnode:
latest)- dev (rchain/rnode:dev)
- testing (rchain/rnode:testing)
- release branch (rchain/rnode:<release branch name>
- tagged release (rchain/rnode: <name of tagged release>)
Testing
Drone CI
Drone is our tool for CI. Please see /wiki/spaces/OP/pages/561971445 for more information.
Bors supports running tests and merge. Please see Bors for more information about this tool and how to use it.
Testing of PRs with CI
- Bors tests compilation on the initial commit and every subsequent push.
- Bors runs the complete test suite prior to merge.
- Fail messages appear in PRs and notifications sent via email to rchain-makers@rchain.coop.
Independent testing
Type checking
Integration tests include static types checking. Type checking can be run locally via this script
Code Block |
---|
./integration-testing/mypy.sh |
Sandbox
There is a mini testnet available for your use. Please see RNode Integration Testing Tool for details.Performance testing
We have a Performance harness for use, All commits merged to dev run on the performance test harness.
Internal testnet
See Results are displayed via Grafana.
Development testnet (devnet)
We have a development testnet for use. Please see /wiki/spaces/OP/pages/647987359 (restricted to core dev team)703692812 for more information. We recommend announcing your use of devnet in the #devnet discord channel to ensure no one else has a test running before your start yours. It is also a best practice to announce when you're done.
Build system
The current system is rchain/build.sbt.
This is system does not meet the following goals stated by Nash here on 9/21/17:
- Builds are hermetic. If I check out code and you check out the same code, our builds should produce the same sequence of bits as output every single time.
- Builds are authoritative. If I check out project-A and you checkout project-B and we both build output-C as a part of our build, then our build of output-C must be hermetic.
- Builds are unambiguous. If I check out project-A and you checkout project-B, then the dependency graphs of each project must be subgraphs of the entire project's dependency graph.
The build system needs to be updated to meet these goals.