jobs-builder: plan of migration - your help is needed

[wainersm]

Context

Recently it was merged #359 (main - #406) which introduced the basics for allowing us to manage the creation and update of Jenkins jobs in http://jenkins.katacontainers.io with the Jenkins Job Builder (JJB) tool. See more information on README.md.

The main benefits of using JJB on our project are:
a) avoid (hard to) reviews on Jenkins XMLs (which are machine-readable jobs representations, not meant for humans)
a) changes will be reviewed and approved before they are commited on Jenkins (just like any other piece of code in the project);
b) changes will be more easily traceable;
c) multiple similar jobs can be generated out of templates

In order to have jobs managed by JJB, their definitions should be on one of the yaml files in the jobs-builder/jobs directory. So far there are only 4 jobs managed with JJB, those are the cache jobs that I maintain; but, IMHO, ideally we should be using that tool to manage all the jobs. Therefore the goal of this issue is to come up with a migration plan.

Pre-req

First of all, I'd like to know whether we have consensus about the use of JJB or not. IMHO all the job owners on the always green CI initiative should agree with that.

Also if anyone strongly opposes to this initiative and/or has a different opinion, that's the proper time to let us know.

Plan

(Draft)

• Announce on kata-dev mailing list and developers meetings
• Define what jobs will be managed with JJB
• Define milestones and timeline

Additional resources

• the view listing the current JJB managed jobs: http://jenkins.katacontainers.io/view/JJB%20managed/

/cc @kata-containers/architecture-committee @kata-containers/ci @ariel-adam @chavafg @kata-containers/redhat @jodh-intel @Jakob-Naucke @jongwu @ananos

[Jakob-Naucke]

I'm in favour of using JJB, I think we can reduce LOC tremendously and make all changes traceable.

[jodh-intel]

+1 from me. Anything to avoid that hellish XML config! ;)

[fidencio]

Huge +1 from me.