Support for Existing Setups

• Support the existing Jenkins and Gerrit setup that the Fabric team uses.

• Support the existing Gitlab-CI setup used for Indy and Ursa while they transition to the new system.

• Automatically driven by the PR process with build results gating PR merges.

New Capabilities

• Support Kubernetes clusters for test net creation, monitoring, destruction.

• Profiling capabilities for unit tests and pipeline steps.

• Must be self-service so that teams have full control over their part of the available resources.

Iroha

Support for Existing Setups:

• Jenkins:

  • ability to self-manage plugins, credentials, job parameters

  • start and restart build feature for maintainers

• Multiplatform/multiarchitecture builds:

  • Linux x86_64, armv7 (hard to find large RAM instances), armv8

  • Windows x86_64

  • MacOS x86_64

• Multi compilers:

  • gcc5, gcc7, clang6, Apple clang (on macos), Visual C++ (windows)

• Instead of compiling on a native platform cross-compilation can be used (but it hurts):

  • Requires a list of specific-version dependencies for each platform

  • Compiling dependencies for other dependencies

• ~ 2-2.5GB RAM per compilation thread (currently builds are running on one-off AWS EC2 instances (c5.2xlarge))

• Uploading artifacts to DockerHub and our Nexus repository (debug builds, etc)

Fabric

Support for Existing Setups:

• Gerrit

•  Jenkins

  • Gerrit integration and automatic and manual trigger of CR builds (reverify, VerifyBuild, etc)

  • Freestyle and pipeline jobs

  • Self-maintained package images for build environment

  • ...

• Multiarchitecture/Multiplatform

  • Linux x86, s390x - build and test

  • Windows - build x86_64

  • macOS - build x86_64

• Docker

  • Compose - Samples, BYFN, EYFN

  • Compose - Fabric Test

  • Services - Fabric (CouchDB, ZooKeeper, Kafka, Chaincode)

• Nexus, maven, docker hub, GitHub for publishing

General Forward Looking Requirements

• Support for declarative, multi-project CI pipeline in the style of gitlab-ci and concourse

  • Pipeline declaration defines flow and dependencies for jobs

  • CI system responsible for setting up dependencies defined in the pipeline

  • Project repo responsible for defining and implementing the logic of a build job

  • Project responsible for placing artifacts into output location managed by CI system

• Simple pipeline status overview

  • At a glance "CI radiator" support

• Support for gated commit promotion through gates

  • Commits to a branch trigger test gates, on success, commit is merged forward to trigger next gate

  • Failed tests prevent promotion; promotion failures motivate maintainers to fix problems

• Access to k8s cluster for "network" testing

  • Access to unpublished/snapshot container images

  • Mechanisms to populate volumes from build system for use by the network

  • Ability to run jobs that use docker and docker compose (KubeVirt or similar are options)