Release management, CI, testing, and build system

Owned by Medha Parlikar (Unlicensed)
Last updated: Jul 20, 2019 by Kelly Foster
2 min read

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

Workflow

  • Dev branch
    • Update
    • Test
    • Build
    • Generate Docker image (rchain/rnode:dev)
    • Push of artifacts to binary repo
  • Master branch (no longer used)
  • Release branches (used as needed)
    • Update
    • Test
    • Build
    • Generate Docker image (rchain/rnode:<tag of release>)
    • Push of artifacts to binary repo
  • Testing branch (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 dev are automatically pushed to this repo: https://build.rchain-dev.tk. 

Docker images automatically push from:

  • 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

./integration-testing/mypy.sh

Performance testing

We have a Performance harness for use, All commits merged to dev run on the performance test harness. Results are displayed via Grafana. 

Development testnet (devnet)

We have a development testnet for use. Please see /wiki/spaces/OP/pages/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.