Hi,

In addition to the classical river names, Functest Kubernetes now delivers Docker tags per Kubernetes release.

(Thank you for all the feedbacks, especially the last one from OOM PTL which convinced me to prioritize this idea)

The new tags simply match all Kubernetes versions from v1.13 : https://build.opnfv.org/ci/view/functest-kubernetes-ng-docker/

For your information, there is no known CVE in all the Docker images (that should be a very key topic especially in OPNFV/Anuket deliverables) : https://build.opnfv.org/ci/view/functest-kubernetes-ng-trivy/

Badly they aren’t yet continuously verified via daily jobs as the classical docker images due to a lack of hardware resources.

This email is also a call for hardware resources ; 2 servers should be enough to install all 8 clusters required for a true gating.

This new Docker builds have been generated thanks to lots of new features in Xtesting CI published in 2021 about Continuous Development.

I proudly announce that all the 3000 Jenkins jobs needed by Functest are now fully generated from a single yml file mostly focusing on docker image, test case and src dir lists.

See all jjbs generated in the releng src dir: https://git.opnfv.org/releng/tree/jjb/functest

As good example, here is the part which generates all Xtesting jjbs for Continuous Development and for Continuous Integration including:

-          patchset verification (test case verification vs compliant SUTs + tox: unit tests, linters, bandit, spell and link checks in docs, etc.)

-          deliverable verification (test case verification vs compliant SUTs)

-          CVE detection

(The Functest ones are just bigger due to the number of testcases and all the changes in test case names across the 6 active branches and it’s multiplied by the number of architectures supported: arm, arm64 and amd64)

- hosts: 127.0.0.1

  vars_files:

    - vars/opnfv.yml

  roles:

    - role: collivier.xtesting

      use_gerrit: true

      git_url: https://gerrit.opnfv.org/gerrit/functest-xtesting

      gerrit_project: functest-xtesting

      jenkins_view_trivy_regex:

        (?!{{ project }}-pi)^{{ project }}-[a-z-0-9.]+-trivy$

      suites:

        - container: xtesting

          tests:

            - first

            - second

            - third

            - fourth

            - fifth

            - sixth

        - container: xtesting-mts

          tests:

            - seventh

      docker_tags:

        - latest:

            branch: master

            slave: lf-virtual1

            dependency: '3.13'

        - leguer:

            branch: stable/leguer

            slave: lf-virtual1

            dependency: '3.12'

        - kali:

            branch: stable/kali

            slave: lf-virtual1

            dependency: '3.11'

        - jerma:

            branch: stable/jerma

            slave: lf-virtual1

            dependency: '3.10'

        - iruya:

            branch: stable/iruya

            slave: lf-virtual1

            dependency: '3.9'

        - hunter:

            branch: stable/hunter

            slave: lf-virtual1

            dependency: '3.9'

We could infinitely debate between Jenkins and Gitlab CI/CD and falsy claim Jenkins Job Builder is too difficult (Hoping we will quickly stop assigning all LFN Releng design issues to Jenkins Job builder).

When we focus on the right abstractions for the project deliverables (all OPNFV test projects could leverage all this work as my company does), the release engineering becomes very simple and maintainable by all.

Hoping to see this kind of discussions in a Dev event rather than the previous marketing lead discussions quickly failing in the different tools and their targets.

To conclude, switching 3000 Functest Jobs to ONAP Releng is now as simple as changing OPNFV to ONAP in git url in this yaml file.

Same if you want to reuse all that work in your company (everything is in place to add bots from your lab if you’re interested to vote on reviews).

I’m now working on the CD part for Kubernetes runners in Jenkins which asks for a few small enhancements (hoping we would update our obsolete shell runners for common builds – that would be a cost saving simply by breaking the LFN project silos which falsy duplicate everything).

And then I would finish the full support of Gitlab CI/CD (only the CI part is currently supported which is already enough for CNTT RC1 and RC2).

Stay tune. Any help is welcome.

Cédric