Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Pipelines

  • 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.

Artifacts

  • Documentation
  • Installation scripts (the main IEC repository)
  • Test logs and results
  • No labels