IEC CI/CD

Architecture

Similar to OPNFV (and old Openstack before the transition to Zuul), Jenkins (and probably JJB) will be used for all CI/CD purposes.

Each POD will be connected as a Jenkins slave node to one public Jenkins master node or to a local Jenkins master node in the current lab (TBD).

IEC Documentation building (on documentation patch submission for peer review) and publishing (on documentation patch merge);
A common approach in opensource projects is to rely on RTD for automating this, but we still need to implement the jobs triggering the builds on our end.
IEC Verify jobs (on patch submission affecting the code in IEC repo) - i.e. linting input YAML/bash/python on patch submission, as well as deployment testing;
IEC Daily jobs (scheduled to run recurrently)
1. Deploy IEC using one of the agreed installers (see below);
2. Run testing suites;
3. Collect logs and publish them (e.g. on Google storage);
Depending on the number of supported installers (e.g. Compass4NFV@OPNFV, Fuel@OPNFV, bash, heat templates, airship-in-a-bottle), we might create a matrix of scenario jobs that validate all or just some combinations of installer/PODs.
For example, one of the installers might not be supported on a certain POD (due to missing configuration data or incompatible hardware), in which case that installer/POD combination should be blacklisted.

To setup a static Jenkins Slave for CI, follow the instructions here but make sure you replace all instances of "opnfv" with "akraino", and in step 5, replace "git clone https://gerrit.opnfv.org/gerrit/p/releng.git" with "git clone https://gerrit.akraino.org/r/ci-management".