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)
  • No labels